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Equipment  SACS  (LOGSACS) . It  identifies  SACS-related  systems 
and  the  data  which  these  systems  contribute  to  establish  the 
SACS  Data  Base.  The  principal  data  bases  that  SACS  draws 
upon  are  the  FAS,  TAADS,  and  TOE.  These  are  supplemented 
by  automated  and  manual  inputs  from  associated  systems.  In 
aggregate,  they  provide  SACS  personnel  and  equipment  require- 
ments and  authorizations  at  the  unit  identification  level 
of  detail  for  all  units  regardless  of  component. 
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1 . 1 BACKGROUND 

This  report  covers  Task  B,  "Identify  the  ADP  Systems  and  the 
Functional  Procedures  Required  to  Produce  and  Validate  Logistical  SACS 
(LOGSACS)  and  Personnel  SACS  (PERSACS)  Outputs,"  of  an  ODCSOPS  project 
entitled  "Analysis  to  Determine  Functional  and  System  Requirements  for 
an  On-Line  Structure  and  Composition  System  (SACS),"  Contract  Number 
MDA90 3- 78-C-044 5 , 26  September  1978. 

1.1.1  The  Task 

Task  B required  that  the  manual  procedures  and  automated  systems 
currently  used  to  produce  the  LOGSACS  and  PERSACS  products  periodically 
provided  to  the  Deputy  Chief  of  Staff  for  Research,  Development,  and 
Acquisition  (DCSRDA) ; the  Deputy  Chief  of  Staff  for  Logistics  (DCSLOG) ; 
and  the  Deputy  Chief  of  Staff  for  Personnel  (DCSPER)  be  identified  and 
documented. 

1.1.2  The  Objective 

The  objective  of  this  task  was  to  identify  and  document  SACS  data 
sources  in  order  to  establish  the  baseline  for  subsequent  definition  of 
feasible  and  cost-effective  changes  to  improve  the  SACS  process. 

1.2  RESEARCH  METHODOLOGY 

Research  methodology  utilized  during  this  task  consisted  of: 

• Gathering  and  examining  existing  documentation  on  manual 
procedures  and  automated  systems. 

• Interviewing  functional  and  systems  personnel. 

• Observing  actual  SACS  operations  during  various  stages  of 
preparation  of  PERSACS  and  LOGSACS  products. 

• Reviewing  and  analyzing  listings  produced  at  various  stages 
of  SACS  processing. 
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1.3  DOCUMENTATION  METHODOLOGY 

The  principal  documentation  methodology  used  in  performing  this 
task  consisted  of  developing  narrative  system  descriptions,  supplemented 
by  flowcharts  to  reflect  data  flow  between  systems,  subsystems,  and 
various  processes  important  to  SACS.  System  descriptions,  attached  as 
appendixes,  are  in  alphabetical  order. 


SECTION  2 
SYSTEMS  OVERVIEW 


2.1  SACS  AND  ITS  PERIPHERAL  SYSTEMS 

SACS  is  a network  of  interrelated  computer  programs  which  con- 
stitute the  Basic  SACS,  LOGSACS , and  PERSACS  as  described  in  Appendixes 
C,  E,  and  G,  respectively.  SACS  provides  vital  planning  and  management 
information  to  the  Army  Staff  (ARSTAF)  and  field  activities  on  personnel 
and  equipment  requirements  and  authorizations.  This  information  is 
developed  by  drawing  upon  and  synthesizing  the  information  contained  in 
the  data  files  of  the  systems  identified  below  and  described  in  the 
appendixes.  The  principal  SACS  end  products  are  the  LOGSACS  and  PERSACS 
magnetic  tapes  which  contain,  respectively,  information  concerning  equip- 
ment and  manpower  for  the  particular  force  selected  for  input  to  the  SACS 
computation.  These  products  are  complete  statements  of  requirements  at 
the  unit  identification  code  (UIC)  level  of  detail.  An  average  SACS 
computation  requires  the  running  of  approximately  80  functional  computer 
programs,  235  utilities  (routines  or  programs  that  serve  common  purpose), 
45  sort  programs,  and  from  125  to  380  reels  of  magnetic  tape. 

2.1.1  Systems  Important  to  SACS 

The  SACS  peripheral  systems  that  provide  data  to  SACS  are: 

• The  Force  Accounting  System  (FAS)  which  provides  aggregated 
unit  data  to  SACS  on  military  personnel  requirements  and 
authorizations.  Personnel  requirements  and  authorizations 
from  FAS  by  military  personnel  identity  (officer,  warrant 
officer,  and  enlisted)  by  command  and  unit  are  the  basic 
control  totals  that  SACS  utilizes  to  ensure  that  PERSACS 
products  do  not  overstate  approved  Army  personnel  end- 
strengths.  FAS  does  not  provide  unit  equipment  information. 
FAS  will  be  replaced  in  the  near  future  by  the  Force  Struc- 
ture Subsystem  of  the  Force  Development  Integrated  Manage- 
ment System  (FORDIMS) . FAS  is  described  in  Appendix  F. 
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SECTION  3 
SACS  PROCEDURES 


3.1  OVERVIEW  OF  SACS  PROCEDURES 

As  previously  indicated,  SACS  is  composed  of  three  parts:  Basic 
SACS,  PERSACS,  and  LOGSACS.  SACS  utilizes  the  M Force  from  FAS,  MTOE 
and  TDA  documented  units  from  TAADS  and,  where  necessary,  TOE  to  estab- 
lish the  SACS  detail  file.  The  BOIP  and  SHN  are  applied  to.  SACS  detail 
data  for  LOGSACS  purposes  only. 

3.2  PREPARING  THE  FORCE 

Preparing  the  M Force  is  a continuing  responsibility  of  ARSTAF 
Force  Managers  which  entails  extensive  coordination  with  the  ARSTAF  and 
the  MACOMs  involved.  Since  the  M Force  is  the  basis  for  the  SACS  force, 
it  is  extremely  important  that  it  be  as  accurate  as  possible  at  the  time 
it  is  frozen  as  the  Q Force  for  a SACS  computation. 

All  actions  that  affect  the  M Force  are  input  to  the  FAS  by  the 
FAS  Branch  in  DAMO-FDA.  These  actions  include: 

• Program  assumptions 

• Approved  Command  Plans 

• Approved  TAADS  documents 

• Approved  SIGMA  transactions 

• Approved  unit  activations,  deactivations,  and  changes  thereto 

• Other  actions  approved  by  Force  Managers 

In  addition  to  maintaining  the  M Force,  when  requested,  the  FAS  Branch 
is  responsible  to  the  SACS  Branch  to  establish  the  P and  L Forces  for 
the  PERSACS  and  LOGSACS,  respectively.  This  latter  responsibility  is 
accomplished  through  SIGMA  (described  in  Appendix  I) , an  interactive 
mini-Basic  SACS  process,  which  is  run  separately  for  each  of  the  two 
aforementioned  forces.  Through  SIGMA,  which  loads  the  selected  force 
and  matches  it  to  both  TAADS  and  TOE,  in  that  order,  discrepancies 
between  corresponding  unit  records  in  FAS,  TAADS,  and  TOE  files  are 
identified  and  the  FAS  Branch  terminal  operator  can  initiate  immediate 


action  to  correct  the  discrepant  conditions.  FAS  Branch  terminal  operator 
must  research  data  and  consult  with  Force  Managers  to  determine  the  proper 
corrective  action.  Once  the  required  corrective  action  is  input,  it 
processes  against  either  the  P or  L Force,  whichever  is  applicable.  In 
order  for  these  SIGMA-generated  corrective  transactions  to  process  against 
the  M Force,  the  Force  Manager  must  review  and  approve  them  and  then  have 
the  FAS  Branch  process  them  against  the  M Force. 

M Force  maintenance,  which  revolves  around  Force  Managers,  requires 
their  attention  be  given  to  many  details  to  assure  accuracy.  Force 
Managers  have  many  actions  in  process  simultaneously  and  sometimes  their 
in-process  actions  are  overtaken  by  events.  As  a result,  some  error  con- 
ditions which  otherwise  would  be  resolved  are  not  corrected  and  are 
carried  forward  into  the  SACS  force.  In  some  instances,  error  conditions 
that  are  not  corrected  can  detrimentally  impact  the  SACS  data  base, 
especially  PERSACS,  by  dropping  units  (such  as  unmatched  TDA  units)  that 
should  not  be  dropped. 

3.2.1  The  SACS  Force 

Figure  3.1  is  an  overview  of  the  Force  Development/Maintenance 
Flow.  This  schematic  depicts  the  macro  flow  of  the  data  maintained  in 
FAS.  FAS  provides  the  most  important  data  to  SACS,  since  these  data 
provide  control  totals  and  the  troop  list.  The  FAS  contains  the  M Force 
and  other  forces.  Forces  other  than  the  M Force  are  established  for 
specific  purposes.  This  report  addresses  only  those  forces  identified 
in  Figure  3.1,  which  are: 

Force  Title 

M Master  Force 

T Developmental  Force 

Q Copy  of  M Force 

P Copy  of  Q Force  for  Personnel 

L Copy  of  Q Force  for  Logistics 

The  T Force  is  developed  by  the  USACAA  from  a copy  of  the  M Force  using 
various  criteria  established  by  DCSOPS  in  conjunction  with  the  Chief  of 
Staff,  Army  Staff,  and  Major  Commanders.  The  T Force  is  forward  looking 


• The  Authorization  Subsystem  (AS)  of  FORDIMS,  formerly  the 
detail  portion  of  The  Army  Authorization  Document  System 
(TAADS)  at  HQDA  provides  unit  detail  data  for  personnel  by 
grade,  military  occupation  specialty  (MOS),  and  branch  and 
for  equipment  by  line  item  number  (LIN).  AS  data  provided 
to  SACS  reflect  the  documentation  of  DA  guidance  by  field 
commands  through  the  Vertical  TAADS  (or  VTAADS) . AS  data 
are  che  field  commanders'  basis  for  requisitioning  of  per- 
sonnel and  equipment.  AS  data  are  processed  through  the 
Summary  TAADS  prior  to  SACS  processing.  Therefore,  for 
brevity  throughout  the  remainder  of  this  report  the  term 
"TAADS"  will  be  used  in  place  of  "Summary  TAADS."  TAADS  is 
described  in  Appendix  J. 

• The  Table  of  Organization  and  Equipment  (TOE)  system  provides 
unit  detail  data  for  both  personnel  and  equipment  at  the  same 
level  as  TAADS.  TOE  data  are  prepared  for  model  "type" 
military  units  that  may  or  may  not  be  documented  in  TAADS. 

TOE  is  described  in  Appendix  K. 

• The  Basis  of  Issue  Plan  (BOIP)  system  provides  data,  currently 
used  in  LOGSACS  computations  only,  on  doctrinal  changes  and 
equipment  modernization  programs,  addressing  specific  pieces 
of  equipment  and  affiliated  personnel  requirements.  BOIP 
data  modify  the  equipment  authorizations  provided  by  TAADS 

or  TOE  by  LIN.  BOIP  is  described  in  Appendix  D. 

• The  Shorthand  Note  (SHN)  system  provides  HQDA  action  officers 
a capability  to  add,  change,  or  delete  equipment  and/or 
quantities  by  LIN  during  the  SACS  process  for  correction  and 
fine-tuning  purposes.  SHN  is  described  in  Appendix  H. 

• The  Automated  Unit  Reference  Sheet  (AURS)  provides  unit 
detail  data  covering  personnel  and  equipment  for  planned 
units  that  have  not  yet  been  incorporated  into  TOE,  Modified 
Table  of  Organization  and  Equipment  (MTOE) , or  documented  in 
TAADS.  AURS  usually  incorporates  BOIP  data,  as  applicable. 
AURS  is  described  in  Appendix  A. 
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The  following  peripheral  systems  are  important  to  SACS  but  do  not 
provide  any  new  data  directly  to  SACS: 

• The  SACS  Information  Gathering  and  Management  Analysis  (SIGMA) 
system  provides  the  capability  to  select  a force  comprising 
specific  units  by  matching  data  stored  in  FAS  with  detail 
data  stored  in  TAADS  fMTOE  and  Table  of  Distribution  and 
Allowances  (TDA) ] and  TOE.  SIGMA  identifies  units  whose 

data  are  unmatched  for  immediate  corrective  action  and  units 
whose  personnel  data  will  be  factored  in  PERSACS.  The  fac- 
toring process  is  explained  in  the  description  of  PERSACS 
in  Appendix  G.  SIGMA  is  explained  in  Appendix  I. 

• The  Automated  Update  Transaction  System  (AUTS)  provides  a 
capability  to  update  the  FAS  data  base  with  data  pertaining 
to  Major  Commands  (MACOM)  and  HQDA-approved  TAADS  documents. 
The  AUTS  transactions  must  be  approved  by  Force  Managers 
before  input  to  FAS  for  updating  the  M-Force  files.  AUTS 

is  described  in  Appendix  B. 

2.1.2  SACS  Data  Analysis  Systems 

Analytic  tools  are  available  to  enable  SACS  personnel  and  equip- 
ment analysts  to  identify  variations  in  authorizations  and  determine  the 
percentage-of-change  when  current  SACS  data  are  compared  to  earlier 

i 

versions  of  similar  SACS  data.  Separate  analytic  systems  have  been 
developed  for  SACS  personnel  and  logistical  products.  They  are: 

• The  Personnel  Authorization  Analysis  System  (PAAS) . PAAS 
can  compare  the  current  PERSACS  product  to  the  previous  two 
PERSACS  products  and  develop  manpower  authorization  varia- 
tion and  percentage-of-change  information. 

• The  Basis  of  Issue  Monitoring  and  Recording  System  (BOIMARS) . 
BOIMARS  can  compare  the  current  LOGSACS  product  to  a pre- 
vious L0GSAC3  product.  The  comparison,  to  be  meaningful, 
must  utilize  similar  outputs.  For  example,  the  1981-1985 
LOGSACS  product  to  support  the  Program  Objective  Memorandum 
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(POM)  should  be  compared  to  the  1980-1984  POM  LOGSACS  pro- 
duct, etc.  BOIMARS  identifies  the  input  sources  and  the 
differing  items  and  quantities  contributed  by  each  source. 

2 . 2 OTHER  SYSTEMS 

There  are  a number  of  other  systems  on  the  SACS  periphery  that 
are  utilized  for  various  force,  manpower,  or  equipment  management  pur- 
poses but  which  do  not  directly  contribute  data  to  SACS.  . Some  of  these 
encompass  multiple  systems/subsystems,  or  models,  or  a file  or  files. 
These  systems  are  components  of  the  overall  Force  Development  Manage- 
ment Information  System  (FDMIS) . They  are: 

• The  Total  Army  Analysis  (TAA) . This  is  an  annual  process 
performed  for  DCSOPS  by  the  US  Army  Concepts  Analysis 
Agency  (USACAA) . It  involves  taking  a copy  of  the  Master 
(M)  Force  and  using  it  as  a basis  for  the  development  of 
an  objective  force.  While  USACAA  is  modelling  this  force, 
it  is  identified  as  the  "T"  force.  USACAA  analysts  apply 
DA-approved  threats,  concepts,  constraints,  doctrine,  and 
techniques  in  performing  the  TAA. 

• The  Unit  Identification  System  (UIS)  maintains  the  registry 
of  Army  units  world-wide  at  the  separate  unit  and  subunit 
level  of  detail.  All  major  commands  and  other  activities, 
agencies,  and  units  must  register  each  unit  with  the  UIS 
prior  to  any  other  action  that  requires  use  of  the  six- 
position  UIC. 

• FORD IMS  is  currently  under  development.  When  completed, 
FORDIMS  will  integrate  the  files  of  the  Army  Force  Program 
(AFP),  Civilian  Budget  System  (CBS),  FAS,  and  TAADS  systems 
using  the  TOTAL  data  base  management  system.  AS  of  FORDIMS 
has  been  implemented  to  replace  the  detail  portion  of  HQDA 
TAADS.  The  Vertical  Force  Development  Management  Information 
System  (VFDMIS)  is  also  under  development  and,  eventually, 
will  replace  FORDIMS. 
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• REPORTER  is  a SACS  utility  program  for  retrieving  data  from 
LOGSACS  or  PERSACS. 

• Basis  of  Change  (BOC)  and  Standard  Study  Number  Cross- 
Reference  (SSN  X-REF)  are  files.  The  BOC  file  contains 
current  and  historical  LIN  data  on  equipment  additions, 
deletions,  and  changes.  The  SSN  X-REF  file  contains  cross- 
reference  data  used  to  group  equipment  in  families  in  order 
to  compute  requirements  for  component  major  items. 

• The  Installation  Manpower  Requirements  (IMR)  model  estimates 
manpower  requirements  by  Army  Management  Structure  Code 
(AMSCO)  for  approximately  45  functions  for  CONUS  Class  I 
installations . 

• The  Manpower  Staffing  Factors  (MSF)  Model  provides  a method 
for  estimating  manpower  requirements  on  the  basis  of  work- 
load and  military  strength  supported. 

• The  Organization  and  Equipment  List  (PEL)  is  a microfilm/ 
magnetic  tape  of  basic  equipment  data  that  are  contained  in 
TOE,  BOIP,  and  the  AS. 

• Rapid  Authorization  Data  Retrieval  (RADAR)  provides  an  on- 
line capability  to  retrieve  data  on  personnel  and  equipment 
required  and  authorized  for  MTOE  and  TDA  units  which  are 
documented  in  TAADS . 

• The  Force  Accounting  Terminal  System  (FACTS)  provides  a 
flexible  retrieval  capability  for  users  of  the  FAS.  This 
retrieval  system  can  key  on  any  data  item  or  discrete  char- 
acter using  Boolean  search  strategy  for  information  retrieval. 

• The  Army-Wide  Requirements  for  Manpower  Support  (ARMS)  Model 
will  compute  the  total  manpower  required  to  support  a given 
command  or  total  Army  military  end  strengths.  ARMS  will 
compute  support  manpower,  both  military  and  civilian, 
utilizing  the  latest  CSGPO-78  manpower  utilization  data. 
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The  Modular  Force  Planning  System  (MFPS)  (formerly  known  as 
the  Battalion  Slice  Planning  Model)  is  a model  utilized  by 
force  programers  and  planners  to  determine  the  total  com- 
position of  a particular  force  when  the  major  combat  units 
are  changed. 
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1.  DAILY  OB  AS  OFTEN  AS  REQUIRED. 

2.  AT  LEAST  THREE  TIMES  ANNUALLY  OR  MORE  OFTEN  AS  REQUIRED. 

3.  SEMI-ANNUAL  OR  AS  EXCEPTIONS  ARE  APPROVED  (MOC). 

4.  EACH  SACS  RUN  - QUARTERLY  OR  MORE  OFTEN. 

5.  ANNUALLY. 


Figure  3.1.  Overview  of  the  Force  Development/Mainter 
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and  each  year  one  additional  year  is  added.  The  USACAA  derives  the  T 
Force  through  multiple  iterations  of  various  model  with  appropriate 
criteria  applied;  thus  the  T Force  is  a new  force  that  meets  said 
criteria  and,  after  further  modification  by  the  ARSTAF  if  required,  it 
is  accepted  by  the  Army.  The  program  year  of  the  T Force  is  then  recon- 
ciled to  the  proper  year  of  the  M Force.  When  this  reconciliation  is 
satisfactorily  completed,  the  T Force  becomes  the  new  M Force.  This 
newly  established  M Force  extends  through  the  POM  years.  The  M Force 
is  maintained  on  a continuing  daily  basis  and  the  current  M Force  is 
copied  as  required  for  various  purposes.  This  report  concerns  itself 
with  the  copy  identified  as  the  Q Force.  Each  time  a SACS  is  run,  the 
M Force  is  frozen  by  taking  a copy  and  naming  it  the  Q Force.  The  Q 
Force  is  further  copied  for  personnel  and  logistic  computations  and 
identified  as  the  P and  L Forces,  respectively.  The  P and  L Forces 
become  the  basic  force  inputs  to  the  PERSACS  and  LOGSACS  processes, 
respectively. 

3.2.2  The  AUTS  Review 

Periodically,  AUTS  is  used  to  provide  update  transaction  lists  to 
Force  Managers.  These  are  important  transactions  that  are  originated 
based  on  the  identification  of  FAS  (M  Force)  units  that  have  no  matching 
TAADS  documentation.  It  is  important  to  SACS  processes  to  have  the  FAS 
(M  Force)  units  annotated  with  the  TAADS  documented  unit  data  so  that 
the  latest  TAADS  requirements  and  authorizations  for  personnel  and  equip- 
ment are  used  in  the  SACS  process.  For  those  FAS  (M  Force)  units  not 
documented,  SACS  force  selection  criteria  cause  the  FAS  (M  Force)  data 
to  be  matched  to  TOE  data,  which  may  be  outdated  when  compared  with 
documented  MTOE  data.  When  the  Managers  review  the  AUTS-created  trans- 
actions, they  may  decide  not  to  process  them  because  of  a variance  in 
the  manpower  totals  (by  military  identity)  between  the  FAS  and  TAADS 
units  or  for  other  reasons.  If  AUTS  transactions  are  not  accepted  to 
update  the  M Force,  SACS  will  match  an  undocumented  unit  to  TOE,  which 
may  present  acceptable  MILID  numbers  but  outdated  MOS  and  LIN  data. 

For  example,  such  a situation  involving  aviation  units  in  Europe  occurred 
within  the  past  year. 


3.2.3  The  FAS  Branch 


The  Chief  of  the  FAS  Branch  in  DAMO-FDA  is  the  ODCSOPS  System 
Manager  of  the  FAS.  The  FAS  Branch  is  the  focal  point  through  which  all 
ARSTAF  actions  impacting  all  forces  must  funnel.  This  funnel  gets 
"stopped  up"  from  time  to  time  by  the  great  volume  of  actions  that  must 
be  processed.  Many  M Force  maintenance  transactions  are  so  vital  that 
the  initiation  of  some  processes  like  SIGMA  and,  hence  SACS,  must  be 
dealyed  until  they  are  processed.  Delays  that  impact  upon  the  SACS 
production  schedule  place  a burden  upon  the  SACS  analvsts  to  attempt  to 
make  up  lost  time.  This  leads  to  additional  pressure  and  long  hours  for 
the  SACS  analysts  to  complete  their  reviews  so  that  the  PERSACS  and 
LOGSACS  products  can  be  produced  on  schedule. 

3.2.4  The  Force  Managers 

The  Force  Managers  in  DAMO-FD  are  the  focal  point  for  actions 
affecting  the  Command(s)  for  which  they  are  responsible.  For  example, 
they  are  responsible  for  reviewing  and  approving  Command  Plans  (or 
troop  lists)  and  for  accepting  or  rejecting  TAADS  data  to  be  entered 
into  the  M Force.  The  Force  Managers  are  provided  computer  printouts 
of  SACS-initiated  corrective  transactions.  For  the  most  part,  these 
lists  present  data  in  a raw  form.  Force  Managers  must  analyze  the  raw 
data  by  comparing  multiple  lists  to  determine  if  the  printouts  accurately 
reflect  the  personnel  requirements  and  authorizations  by  UIC.  In  other 
instances,  voluminous  listings  are  provided  which  Force  Managers  must 
review  page-by-page  to  determine  whether  the  data  reflected  therein  by 
UIC  portray  the  correct  manpower  requirements  and  authorizations. 

Despite  the  automated  systems  that  prepare  listings  for  Force  Managers, 
each  Force  Manager  must  manually  review  and  analyze  each  listing  to 
determine  whether  corrective  actions  are  necessary  to  maintain  his/her 
portion  of  the  M Force. 

3.3  INITIATING  SACS 

Each  SACS  computation,  whether  for  personnel  or  logistics  purposes, 
is  initiated  by  the  ODCSOPS  SACS  Branch  in  DAMO-FDA  by  submitting  a data 
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processing  request  (DPR)  to  USAMSSA.  This  DPR  Is  the  basis  for  starting 
a SACS  cycle,  which  may  be  initiated  to  generate  both  PF.RSACS  and  LOGSACS 
products,  or  just  one  of  the  two  products.  An  AUTS  run  may  be  required 
prior  to  taking  a copy  of  the  M Force  for  SACS.  Figure  3.2  shows  these 
steps  in  schematic  form.  Running  of  the  ACTS  is  an  important  initial 
step  to  generate  FAS  change  transactions  by  comparing  FAS/TAADS/TOE. 

These  transactions  are  candidate  FAS  update  transactions.  They  provide 
data  by  UIC  to  FAS  for  updating  of  the  M Force  to  reflect  a unit's 
authorizat ions  are  properly  documented  in  TAADS.  These  data  are  intended 
to  close  the  loop  between  the  Program  Budget  Guidance  (PBG)  provided  to 
MACOM  by  HQPA  (see  Figure  3.1)  and  approval  of  the  MACOM's  documentation 
of  that  guidance  (through  TAADS)  by  HQDA. 

Current  practices  are  to  process  SACS  five  times  for  PERSACS  and 
four  times  for  LOGSACS  each  year.  Each  SACS  run  is  initiated  by  the 
SACS  Branch  in  DAMO-FDA  via  a DPR  forwarded  to  USAMSSA  which  provides 
the  force  selection  criteria.  Selection  criteria  are:  the  as  of  date, 
force  identification  code  (FICOD) ; component  code  (COMPO) ; type  unit 
code  (TYPCO) ; force  code  (FORCO) ; display/compute  indicator  (DCSMP) ; 
effective  date  (EDATE) ; and  termination  date  (TDATE) . The  DPR  is  the 
notification  for  USAMSSA  to  copy  the  files  reflected  in  Figure  3.2. 

This  action  is  the  freezing  of  the  input  files  for  a SACS  computation. 
Copies  of  the  various  source  files  make  up  the  SACS  data  base  for  both 
the  PERSACS  and  LOGSACS  processes.  Upon  notification  that  the  SACS  files 
are  available,  the  SACS  Branch  coordinates  with  the  FAS  Branch  for  the 
run  of  SIGMA.  SIGMA  is  described  in  Appendix  I. 

3.4  BASIC  SACS 

SIGMA  and  Basic  SACS  are  run  separately  for  both  PERSACS  and 
LOGSACS  computations . Each  SIGMA  run  starts  by  loading  a force  which 
is  designated  either  P or  L depending  on  whether  it  is  to  be  used  for 
PERSACS  or  LOGSACS  purposes.  Both  these  forces  have  their  origins  in 
the  M Force  via  the  Q Force.  The  force  developed  through  the  use  of 
SIGMA,  whether  P or  L,  is  the  force  that  is  used  in  the  computations  to 
develop  the  PERSACS  or  LOGSACS,  respectively. 
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Figure  3.2.  SACS  Processing  Preparatory  Steps 
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TO  Fll 
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sing  Preparatory  Steps 


SIGMA  loads  the  P or  L Force,  overlays  it  with  TAADS  data,  and 
matches  it  with  TOE,  if  required,  using  control  data  of  UIC,  command 
control  number  (CCNUM),  and  EDATE.  SIGMA  "preprocesses"  the  force  using 
documented  unit  data  from  the  TAADS  and  the  TOE  file,  as  required. 

SIGMA's  objective  is  to  obtain  the  best  possible  match  between  FAS  units 
and  TAADS  or  TOE  units.  The  SIGMA  process  utilizes  the  0 Force  (which 
is  now  designated  either  the  P or  L Force)  as  the  base  file.  The  SIGMA 
process  continues  by  matching  the  TAADS  records  to  the  base  file.  In 
case  of  no  TAADS  match,  the  base  file  records  are  matched  to  TOE.  The 
matching  process  is  on  UIC,  EDATE,  and  CCNUM.  During  this  process,  the 
FAS  Branch  terminal  operator  reads  the  cathode  ray  tube  (CRT)  data 
displays  of  unmatched  conditions  and  either: 

• Initiates  corrective  transactions  (in  instances  where 
possible  and  desirable)  so  that  a match  can  take  place,  or 

• Researches  the  mismatch  condition  to  determine  whether  the 
standard  requirements  code  (SRC)  of  the  selected  unit  matches 
on  UIC  and  EDATE.  The  SRC  is  used  to  force  the  CCNUM. 

The  utilization  of  SIGMA  is  an  iterative  corrective  process,  since 
at  each  SIGMA  termination  USAMSSA  provides  the  following  listings  to  the 
FAS  Branch: 

• FAS  units  with  a blank  CCNUM. 

• FAS  units  with  a blank  modified  table  of  organization  and 
equipment  code  (MTOEC) . 

These  listings  are  the  basis  for  continuing  the  iterative  SIGMA  correc- 
tion processing.  This  process  may  require  from  one  to  two  weeks  to 
correct  the  appropriate  force  file  so  that  it  is  acceptable  to  continue 
through  the  SACS  processes.  Once  the  force  is  accepted,  if  SIGMA  is  on 
the  P Force,  the  final  SIGMA  process  is  to  invoke  a routine  that  is 

^"The  Q Force  is  loaded  to  disk  from  magnetic  tape,  at  which  time  it  is 
designated  either  P or  L for  PERSACS  or  LOGSACS  purposes,  whichever  is 
appropriate.  Corrective  transactions  are  processed  against  either  the 
P or  L Force.  The  Q Force  is  maintained  unchanged  to  reflect  the  "as 
of"  M Force  in  the  event  SACS  reruns  are  required. 
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Identified  as  "target  totals."  (Target  totals  is  not  used  with  the  L 
Force.)  This  routine  generates  a printout  of  MACOM  totals  by  MILID. 

The  totals  on  this  printout  are  then  manually  compared  to  a similar 
printout  obtained  from  AFP.  If  the  P-Force  totals  by  MACOM  are  equal 
to  or  less  than  the  AFP  totals  by  MACOM,  then  the  P Force  is  accepted 
to  continue  through  the  automated  Basic  SACS  and  PERSACS  or  LOGSACS  pro- 
cesses, whichever  is  applicable,  to  produce  tape  and  printed  output 
products,  as  appropriate.  Listings  of  the  SIGMA  CRT  displays,  error 
messages,  and  corrective  actions  are  provided  to  DAMO-FD  Force  Managers 
for  review  and  to  determine  whether  the  P cr  L Force  corrections  should 
be  made  to  the  M Force.  If  so,  the  Force  Managers  must  code  the  input 
transactions  to  update  the  FAS. 

Basic  SACS  processing  utilizes  either  the  P or  L Force  file  and 
matches  it  to  TAADS.  The  TAADS  match  is  followed  by  the  "SRC  assembly" 
which  selects  the  detailed  requirements  and  authorizations  for  those 
MTOE  units  that  are  composed  of  multiple  SRC.  The  SACS  detailed  records 
from  SRC  assembly  are  then  matched  to  TOE  records.  The  files  from  the 
TAADS  match  and  TOE  match  processes  are  merged  into  the  TAADS/TOE  SACS 
detail  file.  At  this  point,  the  Basic  SACS  process  is  complete.  The 
identification  of  this  point  is  the  "first  stop."  Reports  are  produced 
for  SACS  Branch  personnel  so  that  they  may  assess  the  quality  of  SACS 
data  up  to  this  point.  These  reports  are  the: 

• TAADS  Match  Reports 

• TOE  Match  Reports 

3.5  PERSACS 

The  PERSACS  programs  used  to  process  the  TAADS/TOE  SACS  detail 
file  through  logic  that  adjusts  the  unit  detail  are  listed  below. 

• The  Remarks  Adjustment  utilizes  the  TAADS  remarks  code  to 
adjust  personnel  strengths  obtained  from  TOE.  The  adjust- 
ment ensures  that  remarks  apply  to  TOE  detail  in  the  same 
proportion  as  they  applied  in  the  TAADS. 
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Interface  deletes  from  the  TAADS/TOE  SACS  detail  file  those 


se’ected  force  units  that  remain  unmatched  to  TAADS  and  TOE. 
Units  in  this  category  are  usually  TDA  type  units. 

• Factoring  balances  TAADS  documented  or  TOE  "type"  detail 

strengths  to  the  FAS  aggregate  strengths  on  a unit-by-unit 
basis.  This  is  explained  in  detail  in  Appendix  G.  Factor- 
ing ensures  that  the  PERSACS  statement  of  personnel  authoriza- 
tions by  grade,  branch,  and  MOS  (extracted  from  TAADS  or  TOE) 
does  not  exceed  aggregate  authorizations  by  MILID  as  reflected 
in  the  M Force.  The  factoring  process  works  from  the  lowest 
to  highest  grades  and,  concurrently,  from  the  highest  to 
lowest  strengths.  For  example:  grade  E3  with  a strength  of 
42  would  be  factored  before  grade  E3  with  a strength  of  18, 
and  all  grade  E3  entries  would  be  factored  before  grade  E4 
would  be  factored.  Factoring  does  not  function  on  strengths 
of  one  (such  as  General  Officer,  Sergeant  Major,  and  single 
MOS  positions). 

Figure  3.3  is  a schematic  overview  of  the  data  flow  and  "SACS 
Processing  to  Generate  PERSACS." 

3.6  LOGSACS 

The  LOGSACS  processes  originate  with  SIGMA  and  Basic  SACS  proces- 
sing the  selected  force  file  identified  as  the  L Force.  L Force  pro- 
cessing is  principally  concerned  with  items  of  equipment  identified  by 
LIN.  Since  the  FAS  does  not  maintain  LIN  data,  the  detailed  LIN  infor- 
mation required  must  be  obtained  from  TAADS,  TOE,  AURS,  BOIP,  or  SHN. 

LIN  information  must,  of  course,  be  related  to  UIC,  CCNUM,  and  command 
code  data. 

Figure  3.4  is  a schematic  overview  of  the  LOGSACS  processes.  The 
first  LOGSACS  process  that  differs  from  the  PERSACS  processes  is  called 
"negative  suppression."  This  process  is  essential  to  bring  all  negative 
LIN  quantities  to  zero.  Negative  LIN  quantities  can  be  generated  during 
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FROM  FIGURE  3.2 


NOTE:  THE  LOGSACS  PROCESSES  UP  TO  FIRST  STOP  ARE  IDENTICAL  TO  PERSACS  BUT  SEPARATE. 


Figure  3.4.  SACS  Processing  to  Generate  LOGSACS 


5ACS  BUT  SEPARATE. 

ng  to  Generate  LOGSACS 


the  SRC  assembly  process  by  subtracting  quantities  greater  than  are 
available.  Negative  suppression  may  be  run  several  times  during  each 
LOGSACS . 

The  BOIP  application  is  the  next  process  and  this  is  the  point 
where  significant  changes  can  take  place.  BOIP  data  apply  to  specific 
LIN  in  all  units  or  to  specific  LIN  in  particular  units  identified  by 
UIC.  The  BOIP  can  cause  deletions  or  additions  of  LINs  and  quantities, 
or  changes  in  quantities  associated  with  a LIN.  BOIP  data  are  applied 
in  LOGSACS  only.  The  automated  application  of  BOIP  to  the  SACS  detail 
data  is  a time  consuming,  complicated  process.  For  illustrative  pur- 
poses, Figure  3.5,  "BOIP  Update  and  Application  to  SACS  Detail  Records," 
depicts  the  many  files  and  programs  that  are  required  in  BOIP  applica- 
tions. 


BOIP  data  are  developed  by  the  US  Army  Training  and  Doctrine 
Command  (TRADOC)  and  provided  to  HQDA  (DAMO-RQR) . BOIP  data  are  main- 
tained by  USAMSSA  and  must  be  updated  before  each  LOGSACS  run.  The 
Force  Integration  Staff  Officers  (FISOs) , DAMO-RQ,  are  responsible, 
in  conjunction  with  SACS  Branch  Equipment  Analysts  for  the  actual  BOIP 
data  used  in  LOGSACS.  The  proper  application  of  BOIP  data  is  a respon- 
sibility of  SACS  Branch  Equipment  Analysts.  The  initial  step  in  updating 
the  BOIP  for  each  LOGSACS  run  is  the  manual  determination  of  which  BOIP 
data  must  be  applied  and  the  provision  of  a list  of  BOIP  serial  numbers 
to  USAMSSA  for  updating  the  BOIP  file  prior  to  its  input  to  LOGSACS. 

This  must  be  done  because  the  BOIP  is  a multiple  file  system  and  in 
some  instances  historical  BOIP  data  are  extracted  for  use  in  the  current 
LOGSACS.  Once  this  process  is  complete,  the  BOIP  data  are  run  to  change 
the  detail  TAADS/TOE  file  and  reports  are  produced  that  reflect  the 
results  of  applying  the  BOIP  data.  SACS  Branch  Equipment  Analysts  per- 
form a thorough  review  and  analysis  of  the  unit  and  LIN  data  as  affected 
by  BOIP  to  determine  whether  the  results  are  acceptable.  If  the  results 
are  acceptable,  the  LOGSACS  processing  continues;  however,  if  the  results 
are  not  acceptable,  the  BOIP  data  are  reviewed  and  analyzed  and  the  SACS 
Branch  Equipment  Analysts,  in  conjunction  with  the  FISOs,  determine  what 
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corrective  action  can  be  taken  by  adding  or  delecting  specific  BOIP 
serial  numbers.  As  a result  of  the  process,  the  SACS  Branch  provides 
another  list  of  BOIP  serial  numbers  to  USAMSSA.  The  update  of  BOIP  and 
the  application  of  BOIP  data  to  the  detail  TAADS/TOE  file  is  repeated. 
This  is  an  iterative  process  which  may  be  repeated  several  times  during 
each  LOGSACS  production  process. 

The  SHN  application  complements  the  BOIP  in  that  it  can  serve  to 
correct  errors  in  the  BOIP,  substitute  for  BOIP  where  the  BOIP  has  not 
been  updated,  or  provide  LIN  detail  for  units  where  LIN  detail  data 
were  either  not  available  or  unacceptable  from  TAADS  or  TOE. 

The  SHN  file  provides  the  only  SACS-related  data  that  are  specif- 
ically the  responsibility  of  and  maintained  by  SACS  Branch  Equipment 
Analysts.  Prior  to  each  LOGSACS  run,  SACS  Branch  personnel  meet  with 
requirements  personnel  in  DAMO-RQR  to  determine  which  SHN  data  should 
be  applied  in  the  current  LOGSACS  process.  As  a result  of  this  meeting, 
SACS  Branch  personnel  develop  or  revise  and  code  the  new  SHN,  and  the 
selection  criteria  applicable  to  the  previously  automated  SHN.  These 
SHN  coded  data  are  provided  to  USAMSSA  for  updating  the  SHN  magnetic 
tape  file  and  for  subsequent  processing  against  the  detail  TAADS/TOE 
file  to  which  BOIP  data  have  already  been  applied.  This  process  results 
in  reports  which  are  produced  for  the  SACS  Branch  Equipment  Analysts  who 
perform  a thorough  review  and  analysis  of  the  results  of  the  SHN  applica- 
tion process.  If  the  results  are  acceptable,  the  LOGSACS  process  con- 
tinues; however,  if  the  results  are  not  acceptable,  the  SHN  data  are 
reviewed  and  analyzed  and  the  SACS  Branch  Equipment  Analysts  determine 
the  type  of  SHN  "fix"  required  to  correct  the  problem(s).  Problems  are 
corrected  by  SACS  Branch  personnel  by  coding  revised  or  new  SHN  data 
and  the  entire  SHN  process  is  repeated.  The  SHN  application  is  an 
iterative  process  which  may  be  repeated  several  times  during  each 
LOGSACS  run. 
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The  Air  Armament  process  is  based  on  zeroing  the  quantities  on 
specific  LIN  and  inserting  quantities  that  are  found  in  the  Air  Armament 
program.  These  quantities  are  ratios  based  on  aircraft  versus  air 
armament  systems.  The  ratios  included  in  these  programs  are  the  respon- 
sibility of  the  SACS  Branch  Equipment  Analysts.  If  a change  is  required, 
they  must  provide  the  new  ratios  and  appropriate  instructions  to  USAMSSA 
for  coding  them  into  the  appropriate  computer  program. 

The  Automated  Tank  Armament  process  is  currently  inoperative.  When 
operable,  it  performs  a function  similar  to  the  Air  Armament  program. 

The  problems  with  the  programs  are  under  study  and  are  to  be  corrected 
USAMSSA.  In  the  interm,  SACS  Branch  Equipment  Analysts  compensate  by 
developing  appropriate  SHN  for  application  at  the  time  that  all  other 
SHN  are  applied.  These  SHN  are  developed  based  on  the  tank  versus  tank 
armament  weapon  system  ratio. 

The  final  review  of  LOGSACS  products  by  SACS  Branch  personnel  may 
determine  that  some  corrections  or  changes  are  appropriate  before  LOGSACS 
magnetic  tapes  and  reports  are  released  to  the  ARSTAF  and  other  users. 

SHN  programs  are  utilized  to  effect  last  minute  corrections.  These  SHN 
are  developed  and  processed  as  stated  above.  The  number  of  SHN  in  this 
application  is  usually  minor  in  comparison  to  the  main  SHN  application. 
The  fine-tuned  LOGSACS  products  are  ready  for  release  to  the  ARSTAF  when 
the  final  process  is  completed. 
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SECTION  4 

THE  SACS  DATA  BASES 


4.1  GENERAL 

The  SACS  is  a network  of  automated  processes  with  manual  data 
review  points  interspersed.  These  review  points  are  used  to  verify 
data  for  accuracy  and  permit  "continue-processing"  or  "go-back-and- 
rerun"  decisions  to  be  made  based  on  review  results.  SACS  Branch 
responsibilities  do  not  include  data  base  maintenance  (e.g.,  update) 
functions.  The  SACS  network  interfaces  with  several  automated  data 
bases  that  are  maintained  by  the  functional  users  of  other  systems. 

The  other  systems  involved  are: 

• FAS  (which  provides  a copy  of  the  M Force). 

• TAADS  (which  provides  MTOE/TDA  documented  unit-level  data). 

• TOE  (which  provides  a copy  of  the  TOE  SRC  header  and  TOE 
SRC  detail  files). 

• BOIP  (which  is  updated  and  provided  for  application  in 
LOGSACS) . 

• SHN  (which  is  developed  and  updated  for  application  in 
LOGSACS) . 

4.2  PERSACS 

The  PERSACS  data  base  is  a composite  of  unit  data  from  the  selected 
SACS  force,  which  for  PERSACS  purposes  is  designated  the  P Force.  This 
force  is  matched  to  unit  detail  data  from  either  the  TAADS  or  TOE  files. 
The  objective  of  this  matching  process  is  to  establish  an  integrated 
PERSACS  data  base  that  can  be  used  to  forecast  Army  personnel  and  train- 
ing requirements.  The  selected  force  is  first  matched  to  TAADS  and  then 
to  TOE  to  obtain  unit-level  strength  data  (required  and  authorized)  for 
the  entire  force  by  grade,  branch,  and  MOS. 

In  utilizing  the  TOE  file,  the  FERSACS  data  base  also  utilizes 
AURS  data  which  are  included  in  the  TOE  file  and  in  it  are  incorporated 
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some  BOIP  data.  To  the  extent  that  BOIP  data  are  included  in  AURS,  they 
are  included  in  PERSACS.  The  vast  majority  of  BOIP  data  exist  in  the 
BOIP  format  only,  hence  a very  large  portion  of  this  important  Qualita- 
tive and  Quantitative  Personnel  Requirements  Information  (QQPRI) , which 
is  currently  reflected  in  the  BOIP,  is  never  applied  to  the  personnel 
unit  detail  data  in  PERSACS  to  reflect  important  unit  changes  that  are 
projected  based  on  revised  Army  doctrine  and  equipment  modernization 
programs.  BOIP  data  are  applied  in  the  LOGSACS,  hence  Army  logisticians 
preparing  and  utilizing  The  Army  Equipment  Distribution  Plan  (TAEDP) 
may  initiate  unit  equipment  distribution  actions  for  which  DCSPER  cannot 
simultaneously  distribute/assign  qualified  personnel.  The  BOIP  are  not 
utilized  in  PERSACS  because  a methodology  for  their  application  has 
never  been  developed. 

The  PERSACS  data  base  must  not  reflect  more  military  personnel  by 
identity  for  a command  than  the  approved  end-strength  constraints  for 
that  command  reflected  in  the  AFP.  Therefore,  the  PERSACS  data  base  is 
loosely  balanced  to  AFP  end-strength  constraints  by  command  and  military 
identity  in  that,  if  the  PERSACS  data  base  reflects  strengths  smaller 
than  the  AFP  numbers,  they  are  generally  accepted.  While  overall  command 
end-strength  balancing  is  important,  it  is  more  important  that  aggregated 
unit  level  military  identity  balancing  take  place  so  that  specific  grade 
and  MOS  authorizations  are  as  nearly  correct  as  possible.  The  methodology 
employed  is  one  of  "factoring"  the  unit  detail  records  (by  grade,  branch, 
MOS,  and  quantity)  either  up  or  down  so  that  the  TAADS  or  TOE  numbers 
equal  the  corresponding  M-Force  totals  by  UIC.  The  factoring  process  is 
performed  by  a computer  program  which  compares  M-Force  authorized  unit 
aggregate  strengths  to  the  TAADS/TOE  authorized  unit  aggregate  strengths 
by  military  identity.  In  instances  where  a variance  exists,  the  dis- 
crepant quantity  and  military  identity  are  identified  and  adjusted.  The 
program  then  looks  at  the  applicable  military  identity  data  by  grade, 
branch,  MOS,  and  quantity  and  commences  to  adjust  the  plus  or  minus 
variance  until  the  aggregated  unit  strengths  are  exactly  in  balance 
with  the  M-Force  aggregated  strengths  by  military  identity.  The  fac- 
toring process  starts  with  the  lowest  grade  with  the  highest  numbers  of 
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authorized  spaces  and  works  toward  the  higher  grades  with  the  lowest 
numbers  of  authorizations  to  achieve  the  desired  balance. 
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4 . 3 LOGSACS 

The  LOGSACS  data  base  is  a composite  of  unit  data  from  the  selected 
SACS  force  which,  for  LOGSACS  purposes,  is  designated  the  L Force.  This 
force  is  matched  with  unit  detail  data  from  either  the  TAADS  or  TOE  files. 
The  objective  of  this  matching  process  is  to  establish  an  integrated 
LOGSACS  data  base  that  can  be  used  to  forecast  Army  equipment  require- 
ments. The  selected  force  is  first  matched  to  TAADS  and  then  to  TOE  to 
obtain  unit  detail  data  that  describe  unit  equipment  requirements  and 
authorizations  by  LIM. 

The  LOGSACS  data  base  has  its  origins  in  the  same  data  that  are 
the  basis  for  the  PERSACS.  However,  since  LOGSACS  is  oriented  exclusively 
to  equipment  and  since  FAS,  which  originally  provided  a copy  of  the  M 
Force  from  which  L Force  is  derived,  has  no  equipment  information,  the 
LOGSACS  process  cannot  perform  a check  and  balance  procedure  comparable 
to  the  aggregate  command  and  UIC  military  identity  strength  checking, 
balancing,  and  factoring  as  in  PERSACS.  The  checking  and  balancing  of 
the  LOGSACS  data  are  the  responsibility  of  SACS  Branch  Equipment  Analysts 
working  in  conjunction  with  FISOs.  This  is  a manual  procedure  which 
requires  the  understanding  and  use  of  BOIP,  SHN,  and  a comparison  analy- 
sis system  called  B01MARS.  Though  the  BOIP  are  TRADOC-deve loped  data, 
it  is  an  ODCSOPS  responsibility  to  determine  which  BOIP  must  be  applied 
in  developing  LOGSACS  products.  SHN  are  developed  and  maintained  within 
the  SACS  Branch  and  serve  to  revise  (generally  to  constrain)  data  pre- 
viously adjusted  by  the  BOIP  and  to  correct  or  to  provide  unit  detail 
data  applicable  to  TDA  units  not  currently  documented  in  TAADS  and 
essential  to  be  Included  in  LOGSACS  products.  BOIMARS  does  not  provide 
or  modify  data  included  in  LOGSACS.  It  performs  a comparison  function 
of  two  similar  LOGSACS  products  and  produces  reports  which  reflect 
equipment  authorizations  by  UIC  and  LIN.  Through  the  BOIMARS  reports. 

SACS  Branch  Equipment  Analysts  can  determine  sources  of  authorizations 
(TAADS,  TOE,  BOIP,  or  SHN)  and  determine  whether  adjustments  are 
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required  (usually  input  via  TAADS)  to  compensate  for  incorrect  authoriza- 
tions. Incorrect  TAADS  equipment  authorizations  can  be  the  result  of 
TAADS  including  two  different  LIN  with  the  same  quantity  (for  a new  and 
an  old  item)  where  one  LIN  should  have  been  deleted. 

The  LOGSACS  check  and  balance  procedures  performed  by  the  SACS 
Branch  Equipment  Analysts  are  concentrated  on  the  procurement  of  equip- 
ment and  missiles,  Army^  (PEMA)-type  items.  The  common  items  of  equip- 
ment procured  from  other  than  direct  procurement  appropriations  (stock 
funds)  are  not  included  in  these  check-and-balance  procedures. 


PEMA  is  an  obsolete  term.  It  is  still  used,  however,  with  reference 
to  major  items  of  equipment. 
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SACS  DATA  SOURCES 
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5.1  USE  OF  FAS  DATA 

The  FAS  provides  the  M Force  to  SACS.  The  FAS  units  selected  for 
a SACS  computation  are  used  for  both  PERSACS  and  LOGSACS.  To  include 
unit-level  detail  covering  personnel  and  equipment  requirements  in  a 
SACS  computation,  the  unit  must  be  recorded  in  FAS.  FAS  provides  unit 
identifying  data  to  SACS  by  the  UIC,  SRC,  CCNUM,  EDATE,  and  other  perti- 
nent data  for  both  MTOE  and  TDA  units.  FAS  also  provides  programed  man- 
power end-strengths  by  MILID,  which  are  the  control  basis  for  the  target 
totals  and  factoring  processes  in  SIGMA  and  FERSACS  , respectively. 

5.2  USE  OF  TAADS  DATA 

TAADS  data  are  utilized  in  SACS  indirectly  and  directly.  The 
indirect  use  is  via  the  AUTS,  whereby  approved  TAADS  documents  are 
entered  into  the  M Force.  The  direct  use  is  via  SIGMA  and  Basic  SACS 
where  TAADS  data  are  matched  to  the  selected  force  data  so  that  errors 
identified  in  this  process  can  be  corrected  to  achieve  an  optimal  match 
of  selected  force  units  to  TAADS-documented  units  in  Basic  SACS  proces- 
sing. The  absence  of  TAADS  documents  or  uncorrectable  errors  in  TAADS 
documents  requires  the  selected  force  units  to  be  matched  to  TOE.  The 
match  to  TAADS  establishes  the  source  of  detail  data  for  personnel  and 
equipment  as  does  the  match  to  TOE,  if  required. 

5.3  USE  OF  TOE  DATA 

TOE  serves  as  the  second  or  alternate  source  of  unit  personnel  and 
equipment  detail  data.  When  selected  force  units  are  unmatched  to  both 
TAADS  and  TOE,  the  procedure  in  PERSACS  is  to  drop  the  unit  out  of  the 
PERSACS  products.  This  can  happen  to  TDA  units.  Conversely,  unmatched 
units  in  LOGSACS  need  not  be  dropped  since  SACS  Branch  Equipment  Analysts 
can  add  unit  equipment  detail  via  the  SUN.  No  such  capability  has  been 
developed  for  PERSACS. 
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In  addition  to  TOE  serving  the  above  purpose,  TOE  serves  as  the 
baseline  document  for  MTOE  units  to  verify  item  and  quantity  require- 
ments or  authorizations  if  there  are  questionable  equipment  authorization 
data  presented  in  the  LOGSACS  review. 

5.4  PERSONNEL  FACTORING 

When  the  M Force  and  TAADS  documents  have  not  achieved  an  aggre- 
gate MILID  strength  balance,  the  PERSACS  factoring  process  forces  a 
balance.  The  factoring  process  in  PERSACS  is,  therefore,  an  alternate 
methodology  to  balance  either  TAADS  or  TOE  unit  aggregate  military 
identity  strengths  to  the  selected  force  unit  aggregate  military  iden- 
tity strengths.  In  those  imbalance  situations,  the  factoring  either 
increases  or  decreases  the  unit  personnel  detail  data  by  grade,  branch, 
MOS,  and  quantity  until  it  exactly  balances  to  the  selected  force  aggre- 
gate military  identity  totals.  This  process  is  explained  in  detail  in 
Appendix  G. 

There  are  situations  whereby  factoring  can  significantly  distort 
unit  personnel  authorizations  when  a significant  increase  or  decrease 
is  reflected  in  the  selected  force  and  has  not  been  documented  in  TAADS. 
The  factoring  first  changes  authorizations  of  the  lowest  grades  with  the 
highest  strengths  and  works  toward  the  higher  grades  with  the  lower 
strengths  until  a balance  is  achieved.  However,  the  factoring  process 
serves  an  essential  role  in  developing  PERSACS.  It  ensures  that  per- 
sonnel authorizations  to  not  exceed  established  manpower  end-strength 
constraints . 

5.5  APPLICATION  OF  BOIP  DATA 

BOIP  and  its  use  are  explained  in  Appendix  D.  The  automated 
update  of  BOIP  and  its  application  to  the  selected  SACS  force  for 
LOGSACS  are  depicted  in  the  general  flow  schematic  in  Figure  3.5. 

The  BOIP  is  developed  in  TRADOC  and  closely  monitored  by  ODCSOPS 
(DAMO-RQR) . It  reflects  data  applicable  to  changes  in  Army  doctrine 


and  to  new  items  of  equipment.  The  BOIP  is  related  to  units  through  the 
use  of  SRC  or  UIC  and  serves  to  change,  add,  or  delete  authorizations. 

The  BOIP  is  applicable  to  personnel  by  MOS,  grade,  and  quantity,  and  to 
equipment  by  LIN  and  quantity. 

The  application  of  BOIP  in  LOGSACS  is  closely  controlled  and  moni- 
tored by  SACS  Branch  Equipment  Analysts.  For  each  LOGSACS,  SACS  Branch 
personnel  in  coordination  with  FISOs  determine  which  BOlPs  are  to  be 
applied.  This  information  is  provided  USAMSSA  for  BOIP  update  prior  to 
its  LOGSACS  application. 

BOIP  development  and  update  require  significant  lead  time  to 
incorporate  revisions  and  changes  in  the  TRADOC-provided  BOIP  file.  To 
compensate  for  untimely  but  required  BOIP  changes,  SACS  Branch  Equipment 
Analysts  develop  appropriate  SHN.  Such  SHN  have  the  effect  of  revised 
BOIP  on  the  LOGSACS  product. 

5.6  APPLICATION  OF  SHN  DATA 

SHN  and  their  use  are  explained  in  Appendix  H.  They  are  developed 
and  manually  coded  by  SACS  Branch  Equipment  Analysts  for  each  SACS  run 
and  provided  to  USAMSSA  for  updating  the  SHN.  SHN  are  currently  applied 
in  developing  LOCSACS  only.  They  are  not  applied  in  PERSACS  since  a 
methodology  has  not  been  developed  for  their  use  to  appropriately  modify 
personnel  authorizations. 

The  application  of  SHN  in  LOGSACS  is  closely  controlled  by  SACS 
Branch  Equipment  Analysts  to  adjust  BOIP  that  have  not  been  updated,  to 
function  as  BOIPs  that  are  under  development,  to  adjust  erroneous  condi- 
tions existing  in  selected  SACS  units  detail,  or  to  provide  detail  LIN 
authorizations  for  TDA  units  when  TAADS-documented  detail  does  not  exist. 

5.7  PERSACS  DATA  VALIDATION 

PERSACS  validation  processes  are  controlled  hv  the  FAS  unit  aggre- 
gated military  identity  strengths  explained  in  Appendix  G,  the  PERSACS 
description.  In  addition,  SIGMA  (described  In  Appendix  I)  has  an  option. 
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identified  as  "target  totals,"  which  develops  a printout  for  use  by  SACS 
Branch  Personnel  to  manually  compare  command  manpower  end-strength  autho- 
rizations to  comparable  AFP  totals. 
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In  addition  to  the  foregoing,  a program  identified  as  the  Personnel 
Authorizations  Analysis  System  (PAAS)  can  compare  the  current  PERSACS 
product  to  two  previous  PERSACS  products  and  provide  SACS  Branch  Per- 
sonnel with  printouts  of  variances  in  personnel  authorizations  over  the 
time  period  of  the  three  PERSACS.  The  PAAS  products  identify  and  analyze 
the  varying  conditions  to  determine  whether  corrections  are  necessary 
prior  to  releasing  the  PERSACS  products.  When  corrections  are  required, 
they  must  be  made  to  the  P Force  and  Basic  SACS  (see  Appendix  C) , and 
PERSACS  (see  Appendix  G)  must  be  rerun. 

5.8  LOGSACS  DATA  VALIDATION 

The  principal  LOGSACS  validation  process  is  through  the  BOIMARS. 
BOIMARS  compares  the  current  LOGSACS  output  to  a previous,  similar 
LOGSACS  output.  The  BOIMARS  reports  are  tools  for  the  SACS  Branch 
Equipment  Analysts  to  access  data  accuracy,  and,  if  required,  initiate 
corrective  action  prior  to  releasing  the  LOGSACS  products.  Corrective 
action  can  only  be  initiated  through  BOIP  or  SHN  and  rerunning  the 
appropriate  LOGSACS  programs. 


SECTION  6 

SACS  SYSTEM  SUPPORT 


6.1  MANUAL  PROCEDURES 

Overall  SACS  procedures  are  outdated.  the  SIGMA  decision  processes 
that  are  required  to  develop  the  SACS  P and  L Forces  are  not  documented 
in  detail.  Despite  the  condition  of  the  specific  SACS  procedures,  well 
written,  completely  current  SACS  procedures  will  not  significantly 
improve  SACS,  since  it  does  not  have  its  own  data  base.  The  procedures 
for  maintaining  the  M Force,  for  documenting  units  via  TAADS,  for  develop- 
ing and  applying  BOIP,  for  developing  SHN,  and  for  developing  AURS  and 
TOE  are  procedures  that  directly  impact  SACS  and  its  capability  to  pro- 
vide timely  and  accurate  data.  The  SACS  procedures,  regardless  of  how 
well  they  may  or  may  not  be  documented,  produce  results  directly  related 
to  the  products  produced  by  the  procedures  of  the  aforementioned  systems. 

ODCSOPS  (DAMO-FDA)  personnel  have  recognized  inadequacies  in  the 
Army  force  manpower  management  procedures  and  systems.  Action  to  correct 
these  inadequacies  are  underway  through  development  of  FORDIMS  with  its 
guidance  tracking  procedures.  When  these  significant  procedures  are 
completely  implemented,  gradual  improvement  in  data  timeliness  and 
accuracy  should  result. 

Regardless  of  these  improved  procedures  and  systems,  the  procedural 
effectiveness  is  dependent  upon  the  important  ingredients  of  a complete 
system.  They  are: 

• Trained  personnel 

• Controlled  responsibilities 

• Consistent  decisions 

• Complete  current  procedures 

9 Timely  error  identification 

• Correct  error  resolution 

• Timely  error  resolution 

• Effective  control  techniques 

• Effective  system  interfaces 
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ODCSOPS  is  handicapped  (as  are  many  ARSTAF  organizations)  by  per- 
sonnel turbulence  caused  by  reassignments  and  retirements  of  both  military 
and  civilian  personnel.  When  experienced  personnel  depart  from  the  force 
and  manpower  management  functions,  their  departure  contributes  to  degrada- 
tion since  their  expertise  developed  over  time  is  lost.  This  reflects  in 
the  SACS  dat3  bases.  Though  degradation  based  on  one  individual's  depar- 
ture and  another  individual's  arrival  is  negligible,  it  is  compounded 
when  departures  occur  in  several  critical  functions  over  a short  period 
of  time.  Personnel  turbulence  coupled  with  the  absence  of  some  aspect 
of  the  listed  ingredients  all  contribute  to  SACS  products  being  less 
than  the  quality  products  which  the  ARSTAF  are  striving  to  produce. 

ODCSOPS  is  also  handicapped  by  the  absence  of  sufficient  staff  to 
completely  document  all  of  the  day-to-day  operational  procedures  and 
provide  for  future  systems  and  procedures  too.  Of  the  items  listed 
above,  the  error  identification  and  resolution  within  and  between  the 
systems  that  contribute  to  the  SACS  data  bases  are  lacking  more  than  any 
of  the  other  ingredients. 

6.2  AUTOMATED  SYSTEM  SUPPORT 

The  automated  systems  that  contribute  data  to  SACS  were  developed 
to  support  a specific  need  and  function  over  the  past  decade.  They  were 
noc  specifically  developed  to  accommodate  SACS  nor  to  provide  the  ARSTAF 
with  data  on  personnel  and  equipment  requirements  and  authorizations  in 
SACS  type  products.  SACS  incorporates  second  generation  automation  con- 
cepts (sequential-magnetic  tape-batch  processing)  through  the  entire 
Basic  SACS,  PERSACS,  and  LOGSACS.  SIGMA  is  near  to  current  state-of- 
art  software  in  that  it  is  activated  via  terminal,  performs  interactive 
conversational  functions,  and  provides  some  operator  prompting. 

The  ADP  support  provided  SACS  is  adequate  if  a "status  quo"  environ- 
ment of  Army  operations  could  be  assumed.  Since  this  is  unrealistic,  the 
ADP  support  currently  available  to  SACS  is  inadequate  to  accomplish  other 
than  "emergency"  or  "essential  modif ications"  to  the  computer  programs. 
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The  support  provided  SACS  is  for  maintenance  of  its  operational  integrity 
only  and  the  support  limitations  are  because  of  the  number  of  available 
systems  analysts/programers  to  work  SACS. 

The  USAMSSA  ADP  support  involves  the  entire  range  of  ADP  functions. 
Each  function  can  impact  the  ODCSOPS  capability  to  produce  timely  and 
accurate  LOGSACS  and  PERSACS  information.  These  functions  are: 

• Systems  analysis 

• Computer  programing 

• Computer  operations 

• Magnetic  tape  handling 

• Cataloging  reels  of  magnetic  tape 

• Controlling  reels  of  magnetic  tape 

• Controlling  computer  programs 

Because  SACS  is  a sequential  processing  magnetic  tape  bound  batch  system, 
it  takes  much  more  clock  time  and  central  processing  unit  (CPU)  time  to 
process  Basic  SACS,  LOGSACS,  and  PERSACS  than  if  it  were  a disk-oriented 
system. 

The  design  of  SACS  presents  computer  operations  a magnetic  tape 
control  problem  because  of  the  large  number  of  reels  of  tape  necessary 
for  each  SACS  run.  SACS  magnetic  tape  requirements  for  each  run  can 
range  from  as  few  as  125  reels  to  380  reels  of  magnetic  tape.  The  effort 
to  catalog,  store,  and  retrieve  this  number  of  reels  is  significant.  The 
control  problems  presented  to  the  CPU  operations  personnel  border  on 
being  unreal  and  operations  must  pay  close  attention  to  handling  of  each 
reel  of  magnetic  tape  to  ensure  that  the  file  being  used  is  proper  and 
that  it  is  correct  by  its  cataloged  serial  number.  The  magnetic  tape 
control  problem  involves  the  LOGSACS  to  a much  greater  extent  that  Basic 
SACS  or  PERSACS  since  the  BOIP  and  SHM  applications  require  many  of  the 
reels  of  magnetic  tape.  Also,  potential  rerun  requirements  are  greater 
in  LOGSACS  and  each  rerun  has  its  attendant  requirements  for  cataloging 
and  controlling  reels  of  magnetic  tape.  As  an  aid  to  control  the 
LOGSACS  operations,  the  LOGSACS  systems  analyst/programer  draws  a 


37 


detailed  flowchart  of  the  entire  LOGSACS  process.  These  flowcharts 
identify  all  reels  of  magnetic  tape  by  file  and  reel  serial  number 
Identity.  The  preparation  of  these  LOGSACS  flowcharts  is  a laborious, 
time-consuming  task.  Thev  are  essential  to  the  control  that  is  impor- 
tant to  ensure  that  LOGSACS  programs  process  the  correct  data  files  in 
the  proper  sequence. 

I 0 

0 

0 

D 

Ij 


APPENDIX  A 

AUTOMATED  UNIT  REFERENCE  SHEET  (AURS) 
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1.  SUBSYSTEM/MODEL /DATA  BASE 

a.  Title:  Automated  Unit  Reference  Sheet  (AURS) 

b.  Status:  Operational 

2.  REFERENCES 

a.  Army  Regulation  71-2,  Basis  of  Issue  Plan.  10  April  1976. 

b.  Army  Regulation  310-31,  Management  System  for  Tables  of  Organiza- 
tion and  Equipment  (The  TOE  System).  2 September  1974. 

c.  TRADOC  Regulation  71-17,  Force  Development  Unit  Reference  Sheets, 
1 July  1973. 


Interviews 

Mr.  W. 

Braswell,  ODSCOPS  (DAMO-RQR) 

Mr.  G. 

Hill,  ODCSOPS  (DAMO-FDA) 

Mr.  J. 

White , TRADOC 

Mr.  R. 

Adams,  USAMSSA 

3.  STAFF  PROPONENT 

ODCSOPS  (DAMO-RQR) : This  office  exercises  Army  General  Staff 
responsibility.  The  US  Army  Training  and  Doctrine  Command  (TRADOC)  is 
charged  with  AURS  development,  and  consolidation  of  AURS  with  TOE  data. 

4.  COMPUTER  SUPPORT 

a.  Agency:  USAMSSA 

b.  Equipment:  IBM  370/165  or  3033 

5.  PURPOSE 

a.  Procedures  for  use  of  a Unit  Reference  Sheet  (URS)  have  been  in 
existence  for  quite  some  time.  However,  the  process  was  manual  and  was 
not  used  extensively.  The  URS  document  proposes  or  portrays  certain 
basic  data  for  organizational  development  purposes.  HQDA  Staff  need 
for  early-on  force  structuring  and  out-year  budgeting  data  led  to  the 
requirement  for  automating  unit  reference  sheets. 

b.  AURS  is  utilized  only  when  requirements  dictate  the  need  to 
establish,  new  type  units  that  will  support  new  equipment  requirements, 
and  new  or  improved  operational  concepts  and  doctrine.  Since  AURS  is 
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required  early-on,  it  roust  be  recognized  that  complete  data  may  not  be 
available.  The  AURS  data  which  are  available,  however,  are  of  signifi- 
cant assistance  to  DCSPER  and  DCSLOG  in  the  planning  and  programing 
necessary  to  support  new  concepts  and  equipment  scheduled  to  come  into 
the  inventory  in  the  near  future. 

c.  TRADOC  is  responsible  for  developing  the  AURS  and  incorporating 
AURS  with  TOE  data  in  the  TOE  master  file.  AURS  applies  to  TOE  units 
only  and  contains  information  similar  to  a TOE  (when  it  can  be  determined) 
as  would  be  applicable  to  any  other  TOE  unit  except  that: 

• Units  developed  under  the  AURS  process  are  always  at  strength 

level  1. 

• The  TOE  type  number  in  the  AURS  record  will  always  carry  a 
"B:  instead  of  an  "H"  in  the  TOE  series  position. 

Once  the  AURS  is  incorporated  in  the  TOE  master  file  and  an  SRC 
is  assigned: 

• TOE  subproponents  are  required  to  maintain  the  AURS  current. 

• Updating/revision  will  be  accomplished  by  revising  the  original 
SRC,  not  by  assigning  a new  SRC  for  each  new  iteration. 

d.  Generally  with  the  development  of  AURS,  a tentative  Basis  of 
Issue  Plan  (BOIP)  and,  in  some  cases,  quantitative  and  qualitative  per- 
sonnel requirements  (QQPRI)  must  be  developed.  As  outlined  in  Appendix 
D covering  the  role  played  by  BOIP  in  a SACS  computation,  BOIP  is  a 
prime  management  tool  used  to  predict  requirements  early  in  the  materiel 
acquisition  cycle.  BOIP  new  equipment  requirements  data  make  an  important 
planning  and  programing  contribution  to  LOGSACS  computations,  but  no 
methodology  has  been  developed  to  make  direct  use  of  BOIP  in  PERSACS 
computations . AURS,  on  the  other  hand,  are  used  in  the  PERSACS  process. 
Though  AURS  applies  only  in  those  cases  where  new  type  TOE  units  are 
constituted  to  accommodate  new  equippage  and  concepts,  AURS  does  provide 
in  those  cases  the  vehicle  for  new  qualitative  and  quantitative  person- 
nel requirements  to  be  input  to  PERSACS  computations  through  the  TOE 
system.  That  input  represents  a manpower  management  contribution  of 
significant  benefit  in  the  form  of  automated  data  which  would  not  other- 
wise be  available  to  PERSACS. 
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6.  CONTRIBUTION  TO  SACS 

AURS  makes  a small  but  important  contribution  to  SACS  primarily  for 
PERSACS  for  the  reasons  addressed  in  paragraph  5d,  above.  BOIP  is  only 
applied  during  the  LOGSACS  process.  While  BOIP  contains  both  the  per- 
sonnel and  equipment  requirements  for  new  operating  systems  being  pro- 
gramed and  budgeted,  only  DCSRDA  and  DCSLOG  have  access  to  these 
requirements  for  use  in  the  planning  and  programing  process.  However, 
if  the  new  equipment  dictates  a new  type  TOE,  development  of  the  required 
AURS  and  the  resulting  input  to  the  TOE  master  file  includes  appropriate 
projected  personnel  requirements.  Since  the  TOE  master  file  is  used  in 
PERSACS,  DCSPER  and  subordinate  manpower  and  personnel  authorities 
acquire  the  benefit  of  planning  and  programing  information  for  personnel 
which  is  comparable  to  that  DCSLOG  has  for  equipment. 

7.  MAJOR  DATA  ELEMENTS 

The  same  elements  that  are  applicable  to  TOE  (see  Appendix  K)  are 
used  in  AURS. 

8.  INTERFACE  WITH  OTHER  SYSTEMS 

Since  AURS  becomes  part  of  the  TOE  master  file,  the  resulting  effec- 
tive interface  for  AURS  is  the  same  as  for  the  TOE  system  (see  Appendix 
K). 
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1.  SYSTEM/MODEL/DATA  BASE 

a.  Title:  Automated  Update  Transaction  System  (AUTS) 

b.  Status:  Operational 

2.  REFERENCES 

a.  USAMSSA  Project  Initiation  Documentation,  Automatic  Update 
Transaction  Summary  System  (AUTS),  1 September  1976. 

b . Standing  Operating  Procedure  for  Maintenance  of  the  Army  Master 
Force  (M  Force),  Force  Programs  and  Structure  Directorate,  Office  of 
the  Deputy  Chief  of  Staff  for  Operations  and  Plans,  February  1978. 

c.  Interviews: 

LTC  A.  Taylor  .ODCSOPS  (DAMO-FDA) 

Ms.  R.  Baker,  ODCSOPS  (DAMO-FDA) 

Ms.  T.  Fasick,  ODCSOPS  (DAMO-FDA) 

Mr.  C.  Danford,  USAMSSA 
Ms.  V.  Hughes,  USAMSSA 

3.  STAFF  PROPONENT 
ODCSOPS  (DAMO-FDA) 

4.  COMPUTER  SUPPORT 

a.  Agency:  USAMSSA 

b.  Equipment:  IBM  370/165  or  3033 

5.  PURPOSE/ROLE 

a.  The  AUTS  serves  two  key  purposes: 

(1)  To  record  in  the  M Force  the  latest  documented  unit  data 
that  have  been  recorded  in  TAADS. 

(2)  To  provide  force  development  managers  with  meaningful  FAS- 
TAADS  information. 

b.  These  purposes  are  fulfilled  by: 

(1)  Automatically  aligning  FAS-TAADS  documented  authorized 
positions  based  on  pre-defined  rules. 

(2)  Providing  management  reports  to  FAS  and  TAADS  Force  Managers 
which  will: 
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• Show  how  the  M Force  will  change  due  to  AUTS  transactions. 

• Show  M Force  positions  vis-a-vis  TAADS  that  need  a decision 
in  order  to  be  changed. 

• Indicate  errors  in  the  FAS  and  TAADS  data  bases  which  need 
to  be  resolved. 

c.  The  AUTS  is  run  on  a monthly  basis  as  near  month  end  as  possible. 

6.  CONTRIBUTION  TO  SACS 

AUTS  provides  a major  contribution  to  the  SACS  process  in  that  it 
provides  data  to  update  the  FAS  file  to  include  all  of  the  latest  docu- 
mented unit  data  that  have  been  recorded  in  the  HQDA  TAADS.  This  update 
is  especially  critical  in  view  of  the  fact  that  the  FAS  is  the  source 
for  all  of  the  units  that  will  be  selected  to  be  studied  in  a SACS  com- 
putation. The  FAS  data  base  provides  SACS  with  the  unit  information  it 
needs  to  identify  uniquely  a unit  being  studied  and  it  provides  the 
elements  for  a TAADS/TOE  interface. 

7.  MAJOR  DATA  ELEMENTS 

While  both  the  FAS  and  TAADS  contain  many  data  elements,  AUTS  only 
makes  a comparison  on  the  following: 

AMSCO  Army  Management  Structure  Code.  (This  element  is  compared  for 
TDA  units  only.)  This  is  the  major  fiscal  language  code  used 
for  Army  planning,  programing,  and  budgeting  and  for  the  Army 
budget  presentation  before  Congress.  TOE  units  have  one  AMSCO 
which  is  recorded  in  the  PROFA  while  TDA  units  may  have  multiple 
AMSCOs  which  are  recorded  in  the  Manpower  Annex  file. 

Al'STR  Authorized  Strengths.  That  portion  of  the  required  manpower 
which  can  be  supported  by  allocated  manpower.  Includes  AUOFF 
(Authorized  Officers),  AUWOF  (Authorized  Warrant  Officers), 

Al’ENL  (Authorized  Enlisted),  AUAGR  (Authorized  Military  Aggre- 
gate), AUUSD  (Authorized  US  Direct  Hire),  AUFND  (Authorized 
Foreign  National  Direct  Hire),  AUIDH  (Authorized  Indirect  Hire), 
and  AUCIV  (Authorized  Civilian  Aggregate). 


CCNUM  Command  Control  Number.  This  is  the  major  FAS/TAADS  linking 

code.  Positions  1 and  2 equal  command  assignment;  positions  3 
and  4 equal  number  of  changes;  and  positions  5 and  6 equal  FY 
document  processed  for  the  unit.  This  applies  to  all  TAADS 
documents . 

EDATE  Effective  Date.  THis  is  the  date  on  which  a unit's  force  struc- 
ture position  becomes  effective. 

MTOEC  Modified  Table  of  Organization  and  Equipment  Control  Number.  This 
code  identifies  a specific  modification  of  a TOE  by  number  within 
each  command. 

SRCTO  Standard  Requirements  Code.  This  identifies  the  basic  Table  of 
Organization  and  Equipment  of  both  personnel  and  equipment,  plus 
variations  for  a TOE  unit. 

STSTR  Structure  Strengths.  For  TOE  units  this  is  the  full  TOE  strength 
and  for  MTOE  and  TAD  units  it  represents  the  "Required  Strength." 
For  MTOE  units,  structure  strength  is  always  at  level  1.  Struc- 
ture strength  for  TDA  units  is  individually  determined  to  support 
the  unit's  requirements.  Included  is  STOFP  (Structure  Officer), 
STVJOF  (Structure  Warrant  Officer),  STENL  (Structure  Enlisted), 
STAGR  (Structure  Military  Aggregate),  and  STCIV  (Structure 
Civilian  Aggregate) . 

TMCCC  Type  MTOE  Indicator.  This  code  indicates  the  series  that  defines 
the  basis  or  organization  and  authorization  of  a TOE  unit. 

UICCC  Unit  Identification  Code.  This  is  an  alphanumeric  code  which 
uniquely  identifies  a particular  TOE  or  TDA  unit. 


8.  INTERFACE  WITH  OTHER  SYSTEMS 

AUTS  principal  responsibility  is  to  interface  TAADS  with  FAS. 


APPENDIX  C 

BASIC  STRUCTURE  AND  COMPOSITION  SYSTEM  (BASIC  SACS) 


1. 


1 . SUBSYSTEM! /MODEL /DATA  BASE 

a.  Title:  Basic  Structure  and  Composition  System  (Basic  SACS) 

b.  Status:  Operational 

2 . REFERENCES 

a.  Handout  in  Support  of  USAMSSA  Inter/Intra  Divisional  Briefings, 

Computational  Systems  Branch,  US  Army  Management  Systems  Support  Agency, 

25-29  June  1973. 

b.  Force  Accounting  System  User’s  Guide,  Force  Accounting  and  Systems 
Division,  Office  Deputy  Chief  of  Staff  for  Operations  and  Plans  (ODCSOPS) , 

HQ  DA,  March  1976. 

c.  Army  Regulation  71-2,  Basis  of  Issue  Plans,  19  April  1976. 

d.  Structure  and  Composition  System  (SACS)  User's  Guide,  US  Army 
Management  Systems  Support  Agency,  undated. 

e.  Army  Regulation  310-31,  Management  System  for  Tables  of  Organiza- 
tion and  Equipment  (The  TOE  Systems),  2 September  1974. 

f.  Army  Regulation  310-49,  The  Army  Authorization  Documents  System 
(TAADS),  10  June  1975. 

g.  CSR  18-11,  Force  Development  Management  Information  System.  18 
February  1976. 

h.  Interviews  with: 

MAJ  R.  L.  Meredith,  0DSC0PS  (DAMO-FDA) 

Mr.  G.  P.  Hill,  ODCSOPS  (DAMO-FDA) 

Mr.  C.  P.  Joyce,  USAMSSA 
Mr.  S.  D.  Haupt,  USAMSSA 
Mr.  R.  M.  Walden,  USAMSSA 

Mr.  R.  Frank,  USAMSSA  q 

Mr.  R.  G.  Good,  USAMSSA 

3.  STAFF  PROPONENT 
ODCSOPS  (DAMO-FDA) 

4 . COMPUTER  SUPPORT 

a.  Agency:  USAMSSA 

b.  Equipment:  IBM/ 370/ 165 
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5.  PURPOSE /ROLE 


a.  General 

Basic  SACS  processing  an<l  execution  establishes  a SACS  environ- 
ment common  to  both  the  military  personnel  (PER)  and  equipment  (LOG) 
computational  systems.  Otherwise  separately  maintained  discrete  files 
are  integrated  into  one  working  detail  file.  Subsequent  LOG  and  PER 
processing  activities  use  this  detail  as  a base  on  which  to  perform  their 
respective  SACS  computations. 

b.  Specific 

Basic  SACS  is  a SACS  endogenous  set  of  processing  procedures 
divisible  into  five  discrete  functions: 

(1)  Force  Selection 

(2)  The  Army  Authorization  Documents  System  (TAADS)  Hatch 

(3)  Standard  Requirements  Code  (SRC)  Assembly 

(4)  Table  of  Organization  and  Equipment  (TOE)  Match 

(5)  Detail  Merge 

Each  of  these  processing  functions  is  integral  to  the  Basic  SACS  and  each 
is  described  in  ensuing  paragraphs. 

(1)  Force  Selection.  The  Force  Accounting  System  (FAS)  is  the 
vehicle  used  by  the  Department  for  force  accounting  and  force  structuring. 
FAS  is  designed  as  a multiple  force  system  in  which  the  Master  Force 
and  several  alternate  planning  forces  are  retained  in  a single  data  base. 
This  file  is  the  original  source  for  the  units  studied  in  a SACS  computa- 
tion. 

The  first  thing  done  in  any  SACS  computation  is  to  select  a 
force  for  study.  The  force  selected  is  a product  of  the  SACS  Information 
Gathering  and  Management  Analysis  (SIGMA)  "pre-processor."  Criteria  for 
force  selection  include: 

• Component  Code  (COMPO) 

» Type  Code  (TYPCO) 

• Force  Code  (FORGO) 

• Display/Compute  (DSCMP) 

• Effective  Date  (EDATE) 

• Termination  Date  (TDATE) 


These  criteria  are  specified  within  the  Data  Processing  Request  (DPR) 
prepared  by  ODCSOPS  (DAMO-FDA)  and  delivered  to  USAMSSA.  DPR  selection 
criteria  are  mirrored  in  the  SIGMA  processing  which  implements  force 
selection.  That  is,  the  SIGMA  process  provides  Basic  SACS  with  the 
selected  force  and  components  (e.g.,  active.  Army  Reserve,  National 
Guard)  conforming  to  DPR  force  selection  criteria  by  type  unit  and  for 
the  time  period  under  study.  The  selected  force  structured  through  the 
SIGMA  process  is  "released"  to  USAMSSA  and  constitutes  the  Basic  SACS 
Selected  Units  File  on  which  processing  is  based.  From  this  point, 
processing  may  proceed  toward  alignment  of  detailed,  documented  personnel 
(military  only;  civilian  personnel  computations  are  not  a part  of  either 
Basic  SACS  or  the  overall  system  encompassed  by  SACS),  and  equipment 
characteristics  for  each  unit  under  study. 

In  order  to  effect  alignment  of  given  units  with  their  respec- 
tive documented  detail  characteristics,  certain  data  elements  common  to 
the  files  to  be  interfaced  are  used  as  keys,  thus  facilitating  an  inter- 
file indexing/addressing  capability.  Elements  of  particular  significance 
in  the  file  interfaces’ (i.e. , having  inter-file  referencing  utility) 
within  Basic  SACS  include: 

• The  Unit  Identification  Code  (UIC) , a unit  unique  alpha- 
numeric code  assigned  to  a particular  TOE  or  Table  of  Distribution  and 
Allowances  (IDA)  unit  (e.g.,  WCGD99). 

• The  F.DATE  indicating  the  date  on  which  a unit  is  activated, 
inactivated,  or  reorganized  (e.g.,  330930,  equating  to  30  September  1983) 

• The  TAADS  document  number  identifying  the  TAADS  document 
to  be  used  in  developing  manpower  or  equipment  requirements  (e.g., 
M1W012AA) . 

• The  TOE  document  number  identifying  the  TOE  document  which 
can  be  used  in  developing  manpower  or  equipment  requirements  (e.g., 
0704HE101). 

Each  unit  of  the  force  selected  for  a given  SACS  computation 
must  be  matched  to  a detailed  unit  manpower  and  equipment  document  (e.g., 
TOE,  modified  TOE,  or  TDA) . Lacking  detailed  manpower  and  equipment  com- 
position documentation,  a unit  may  be  disallowed  proper  computational 
processing  in  both  PERSACS  and  LOGSACS. 
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(2)  TAADS  Match.  TAADS  match  processing  is  a first  order  attempt 
to  pair  units  with  their  detailed  resource  composition  documents.  The 
design  objective  of  TAADS  is  to  provide  each  Army  unit  with  a document 
containing  its  respective  personnel  and  equipment  requirements  and  autho- 
rizations. TAADS  documents  reflect  "tailored"  quantities;  the  system 
seeks  to  provide  each  Army  unit  with  its  own  TAADS  document  detailing 
"tailored"  personnel  and  equipment  authorizations.  TAADS  incorporates 
both  TDA  and  modified  TOE  (MTOE)  documentation. 

• TDA  documents  are  individually  constructed  from  the  outset. 
Each  is,  effectively,  individually  "tailored"  to  provide  the  necessary 
manpower  and  materiel  resources  to  successfully  execute  specialized 
missions  outside  the  combat,  combat  support,  combat  service  support,  and 
certain  other  selected  areas  permitting  "standardized"  unit  structure. 

• MTOE  documents  cover  the  last  mentioned  mission  areas. 

Each  is  predicated  upon  a "standard"  base  case  TOE  document  (e.g.,  artil- 
lery battalion,  infantry  battalion,  signal  brigade,  maintenance  battalion). 
The  base  case  unit  manpower  and  equipment  structure  may  evolve  and  be 
modified  over  time  as  specialized  mission  objectives  and  the  operational 
environment  change.  Resulting  MTOE  documentation  is  incorporated  in 
TAADS,  reflecting  for  each  unit  the  manpower  and  materiel  resources 
authorized  to  successfully  execute  its  combat,  combat  support,  or  combat 
service  svipport  mission  in  the  postulated  operational  environment. 

TAADS  match  is  directed  toward  anchoring  each  Army  unit  in 
the  selected  force  to  its  respective  documented  resource  detail  in  the 
TAADS,  if  such  documentation  exists.  TAADS  match  is  done  using  the 
following  key  data  element  vehicles: 

• UIC,  as  defined  above. 

• Command  Control  Number  (CCNYM) , a unit  unique  alphanumeric 
code  used  to  identify  separate  modifications  to  the  TOE  documentation  of 
a specific  TOE  unit  (e.g.,  AR0179). 

When  a TAADS  match  occurs  (i.e.,  properly  identified  unit 
manpower  and  equipment  documentation  is  successfully  located  in  TAADS, 
and  is  accepted  by  the  systems  operator)  military  personnel  or  equipment 
information  is  written,  respectively,  to  the  PERSACS  or  LOGSACS  detail 
file,  whichever  is  applicable. 


• Military  positions  are  carried  at  the  grade,  branch,  and 
military  occupational  specialty  (MOS)  detail  level-  As  outlined  in  our 
basic  Report  and  detailed  in  our  Appendix  C on  PERSACS,  a "Factoring" 
process  is  applied  in  PERSACS  to  reconcile  TAADS  documented  manpower 
authorizations  (commissioned  officer,  warrant  officer,  enlisted) — 
required  strength  documentation  is  not  affected  by  any  factoring  pro- 
cedure— with  the  FAS  programed  M Force  such  that  PERSACS  authorized 
officers,  warrant  officers,  and  enlisted  personnel  will  equal  the  con- 
strained totals  in  the  programed  force.  The  "Factoring"  subsystem 
effectively  allows  for  adjustment  of  the  military  manpower  authorizations 
in  TAADS,  or  a given  strength  level  in  TOE  (see  "TOE  Match"  below),  until 
the  constraining  quantity  limitations  in  FAS  are  met. 

• Equipment  is  carried  at  the  line  item  number  (LIN)  detail 
level.  The  PERSACS  "Factoring"  subsystem  briefly  referenced  above  is 
not  applied  to  LOGSACS  equipment  quantities. 

• Each  personnel  and  equipment  data  record  obtained  contains 
an  EDATE  as  well  as  a termination  date  (TDATE) . These  dates  apply  to 
each  unit’ and  to  its  associated  equipment  and  personnel;  they  serve  to 
bracket  the  time  frame  in  which  a given  unit's  resource  requirements  and 
authorizations  are  valid. 

When  a TAADS  match  does  not  occur,  the  causative  factors  may 

be: 


• Through  errors  it  is  possible  that  a unit  in  the  Selected 
Units  File  has  been  incorrectly  identified.  This  eventuality  is  remote; 
unit  identification  errors  are  generally  eliminated  by  SIGMA  edit  and 
correction  pre-processing. 

• Through  error,  omission,  or  time  delay,  properly  identified 
unit  manpower  and  equipment  documentation  is  not  resident  within  TAADS. 
Time  delay  becomes  a causative  factor  bv  virtue  of  the  time  required  for 
programed  force  structure  actions  to  be  translated  into  unit  manpower  and 
equipment  detail  and  incorporated  in  TAADS.  The  time  required  will  vary. 
It  is  a function  of  current  procedure  requiring  bulk  allocation  of  re- 
sources to  major  commands  (MACOMS)  which  respond  with  manpower  and  equip- 
ment detail  by  unit  for  inclusion  in  TAADS  after  HQDA  approval.  In  some 
cases,  inclusion  in  TAADS  of  initial  TDA  or  MTOE  documentation  for  a new 
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unit  may  not  have  occurred  by  the  time  a SACS  computational  study  is 
initiated . 

• Through  intervention  of  system  operators,  a TAADS  mismatch 
may  be  "forced."  That  is,  though  unit  detail  documentation  is  properly 
identified  in  TAADS,  it  is  rejected  by  the  operator  as  being  deficient, 
in  some  cases,  the  perceived  unit  detail  documentation  deficiency  which 
is  the  proximate  cause  of  the  reject  decision  may  stem  from  either  the 
error,  or  the  omission,  or  time  delay  factors  referenced  above,  the 
latter  affecting  timely  inclusion  in  TAADS  of  unit  detail  reflecting 
Army  Force  Program  changes.  It  is  emphasized  here  that  TAADS  mismatch 
decisions  and  their  impact  are  effectively  pre-assessed  during  the  SIGMA 
process,  referenced  earlier  in  this  Appendix,  and  discussed  in  detail  in 
Appendix  I.  That  is,  they  normally  do  not  emerge  full-blown  for  the 
first  time  to  confront  the  operator  and  demand  a decision  during  the 
TAADS  match  process  of  Basic  SACS.  The  measures  taken  to  correct  errors 
and  omissions  such  that  TAADS  mismatch  is  minimized  are  discussed  in 
SIGMA  Appendix  I.  Whether  those  measures  can  be  improved,  and  whether 
or  not  they  fully  involve  the  resource  managers  who  are  or  should  be 
most  vitally  concerned,  are  issues  briefly  treated  in  our  basic  Report 
and  requiring  subsequent  evaluation  in  the  course  of  our  review  of  the 
overall  methods,  procedures,  and  systems  encompassed  by  SACS.  However, 
the  following  observations  regarding  the  so-called  "forced"  TAADS  mis- 
match should  be  made  here: 

- The  apparent  implication  of  the  TAADS  match  rejection 
decision  is  that  "better  fit"  unit  detail  resource  documentation  is 
available  elsewhere  and  will  be  more  in  consonance  with  actual  unit 
resource  attributes  prescribed  in  the  real  world  in  the  Army  Force  Pro- 
gram. 

- Where  the  decision  to  "force"  a mismatch  is  based  upon 
rejection  of  manpower  detail  contained  in  TAADS,  that  decision  either 
explicitly  or  implicitly  reflects  3n  unwillingness  to  accept  the  auto- 
mated "Factoring"  process  as  a means  of  bringing  TAADS  personnel  docu- 
mentation into  aggregate  alignment  with  the  Army  Force  Program.  The 
"Factoring"  process  has  previously  been  discussed  briefly  herein,  is 
detailed  in  our  PERSACS  Appendix  G.  and  is  discussed  in  our  basic  Report 
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including  the  larger  impacts  of  rejecting  the  "Factoring"  process  as  a 
means  of  accommodating  to  manpower  program  constraints. 

Whatever  the  reason  for  the  lack  of  a TAADS  match,  and  given 
proper  subsequent  user  or  analyst  action/input,  alternate  means  are 
available  for  aligning  units  in  the  selected  force  with  their  respective 
manpower  and  equipment  document  detail.  Though  available,  these  alter- 
native means  are  not  always  formalized,  are  not  always  used  and,  if  used, 
may  not  always  produce  the  most  desirable  result.  In  any  event,  it  should 
be  emphasized  here  that  a TAADS  mismatch  in  Basic  SACS  does  not  result 
in  dropping  the  unit  concerned;  while  that  may  be  an  eventual  result, 
as  outlined  below,  the  unit  concerned  is  carried  forward  through  the 
Basic  SACS  processing  steps  for  disposition  in  the  course  of  LOGSACS/ 
PERSACS  processing. 

When  a TAADS  match  does  not  occur  for  a selected  TDA  unit, 
the  only  other  source  of  unit  resource  detail  is  through  analyst  input 
using  the  Shorthand  Notes  (SHN)  override  system.  SHN  is  discussed  in 
detail  in  other  appendixes  (see  especially  LOGSACS  Appendix  E)  and  is 
also  discussed  in  the  basic  Report,  but  the  following  points  require 
particular  emphasis  here: 

• Using  SHN,  the  analyst  may  supply  equipment  detail  for  the 
selected  TDA  unit  in  the  course  of  LOGSACS  processing. 

• However,  no  such  provision  is  available  for  the  unmatched 
TDA  unit  in  PERSACS.  Such  an  unmatched  unit  will  simply  be  dropped  by 
PERSACS  at  "Interface"  processing  time  (see  PERSACS  Appendix  G)  and 
effectively  excluded  from  the  PERSACS  output  computation.  All  subsequent 
management  and  resource  actions  which  do  not  manually  take  account  of  this 
substantive  deficiency  in  PERSACS  output  data  will  be  deficient  in  com- 
mensurate measure.  Hence,  the  previously  discussed  early  role  of  SIGMA 

in  resolving  nondocumented  TDA  unit  and  related  deficiencies  is  a par- 
ticularly critical  aspect  of  the  compelling  need  to  provide  complete  and 
accurate  manpower  resource  data  to  the  Army  manpower  and  personnel  manager. 

When  a TAADS  match  does  not  occur  for  a selected  MTOE  unit, 
the  alternative  of  obtaining  a TOE  match  remains  available,  is  a part  of 
Basic  SACS  processing,  and  is  discussed  below.  Before  proceeding  with 
that  discussion,  the  following  points  require  particular  emphasis  here: 
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• Since  default  to  the  TOE  match  process  automatically  results 
in  the  case  of  a TOE-type  unit  on  which  there  was  no  TAADS  match  (or  on 
which  a TAADS  mismatch  was  "forced"),  manpower  data  are  not  summarily  lost 
to  the  system,  as  they  may  be  in  the  case  of  TDA  units  by  virtue  of  the 
fact  that  SHN  does  not  apply  to  PERSACS  output  computations.  TOE  manpower 
detail  is  available  and  is,  effectively,  substituted  for  the  detail  which 
would  have  been  available  had  there  been  an  accepted  TAADS  match. 

• However,  a default  to  the  TOE  match  process  does  result  in 
summary  loss  of  the  important  "tailored"  resource  detail  built  into  MTOE 
documentation  carried  in  TAADS.  The  loss  of  tailored  MOS  detail,  for 
example,  can  have  particularly  substantive  impact  upon  PERSACS  outputs 
and  subsequent  manpower  recruitment,  training,  and  management  costs  and 
capabilities  within  the  Department.  Comparative  data  are  not  immediately 
available  at  this  time  to  permit  assessment  of  the  relative  manpower, 
materiel,  and  dollar  impacts  of  "forced"  TAADS  mismatches  of  otherwise 
legitimate  TAADS  matches;  or  the  relative  advantages/disadvantages  of 
retaining  the  "tailored”  TAADS  baseline  as  the  starting  point  for  distri- 
bution of  a resource  increment  or  decrement,  in  lieu  of  "forced"  mismatch 
and  recourse  to  the  T l standard"  baseline. 

(3)  SRC  Assert  : tch  SRC  uniquely  identifies  a specific  TOE. 

An  SRC  is  the  vehicle  e-o loved  to  identify  each  document  in  the  TOE 
file  which,  by  design  or  de-'ault,  will  be  used  in  the  TOE  match  process 
as  the  source  of  unit  resource  detail. 

As  indicated  at  the  beginning  of  this  appendix,  FAS  is  the 
source  of  the  SIOIA-generated  Selected  Units  File  constituted  as  the 
essential  first  step  in  any  SACS  computation.  All  of  the  data  elements 
in  FAS  are  carried  in  SACS.  The  SACS  Selected  Units  File  is  augmented 
by  essential  data  from  two  FAS  files  having  special  relevance  to  the  SRC 
assembly  and  TOE  match  processes  of  SACS:  the  Multiple  Forces  File 
(PROFA) , and  the  Motes  File. 

• A limitation  of  FAS  is  that  only  one  SRC  per  unit  record 
is  carried  in  PROFA.  It  often  occurs,  however,  that  multiple  TOE  docu- 
ments are  required  to  adequately  characterize  a unit's  complete  organiza- 
tional structure  in  a SACS  study  time  frame.  Multiple  SRCs  which  augment 
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Che MTOE  documentation  to  be  applied  in  unit  resource  calculations  in 
SACS  must  be  brought  together  or  "assembled"  in  preparation  for  the  TOE 
match. 

o The  FAS  Notes  File  helps  to  fill  that  need.  It  was  designed 
to  augment  PROFA  by  identifying  any  additional  SRCs  which  might  be  appli- 
cable to  the  subsets  in  that  forces  file.  The  Notes  File  is  a special 
purpose  source  containing  the  additional  SRCs  which  combine  to  reflect 
the  organizational  and  resource  composition  of  a given  unit.  It  may  be 
updated  by  addition/deletion  of  SRC  Notes,  as  appropriate. 

The  required  bringing  together  of  applicable  SRCs  is  accom- 
plished through  cross  referencing  between  Notes  File  content  and  the 
Selected  Units  File,  using  the  following  key  elements: 

• Force  Identification  Code  (FICOD)  identifies  the  particular 
FAS  force  in  the  multiforce  file. 

• COMPO  identifies  the  duty  status  of  the  unit  where:  1 = 
Active  Army,  2 = National  Guard,  3 = Army  Reserve,  4 = Unmanned  Army, 

B * Restructured  Reserves,  C = Mobilization. 

• UIC. 

• ED ATE. 

For  example,  a particular  unit  in  our  selected  force  might 
have  an  SRC  augmentation  in  the  Notes  File  formatted  as: 

UIC  EDATE  SRC  TIMES  SIGN 

WABCAA  790630  07047H000  002  + 

This  would  serve  to  increment  (+)  the  specified  unit  (WABCAA)  by  2 Rifle 
Companies  (0704H000)  on  30  June  1979.  The  increment  augments  the  speci- 
fied unit  indefinitely  or  until  deleted  by  an  opposite-signed  SRC  Notes 
File  entry: 

UIC  EDATE  SRC  TIMES  SIGN 

WABCAA  800630  07047H000  002 

In  sum,  the  SRC  assembly  process  is  an  assimilation  and  inte- 
gration of  all  TOE  documented  augmentations  to  the  elements  of  the  Selected 
Unit  File.  The  SRC  assembly  process  is  evaluative  to  the  extent  that,  for 
the  time  frame  identified  for  SACS  study,  tlv.  impact  of  discrete  SRCs  on 
unit  organization  is  the  sum  of  all  effective  plusing  (+)  and  minusing  (-) 


across  the  time  period  under  study.  When  SRC  assembly  is  complete,  each 
unit  destined  to  obtain  its  authorizations  from  TOE  will  be  characterized 
as  to  its  organizational  structure  through  the  aggregation  of  all  agument- 
ing  SRCs,  and  is  then  prepared  to  enter  the  TOE  match  process. 

(4)  TOE  Match.  The  TOE  match  is  designed  to  unite  each  MTOE  unit 
in  the  selected  force  remaining  unmatched  (because  no  TAADS  document  was 
found  or  a TAADS  mismatch  was  "forced")  with  the  "standard"  documented 
manpower  and  equipment  detail  contained  in  applicable  TOE  documents. 
Assembled  SRCs  are  the  match  vehicles  used  to  identify  TOE  documents 
containing  resource  detail  for  these  MTOE  units. 

When  a TOE  match  occurs,  military  personnel  and  equipment 
information  is  written,  respectively,  to  the  PERSACS  or  LOGSACS  detail 
file.  Outcomes  essentially  identical  to  those  we  previously  discussed 
in  the  case  of  a successful  TAADS  match  are  applicable: 

• Military  positions  are  carried  at  the  grade,  branch,  and 
MOS  detail  level.  A "Factoring"  process  will  be  applied  to  PERSACS  to 
reconcile  TOE  documented  strengths  with  programed  Army  force  structure 
quantity  constraints  as  reflected  in  FAS.  (Note:  For  G-series  TOEs, 
strength  level  1 is  used  as  the  base  line.  For  H-series  TOE  documents, 
the  "authorized"  strength  level  is  used  as  reflected  by  the  12th  digit 
in  the  SRC  shown  in  FAS.) 

• Equipment  is  carried  at  LIN  detail  level. 

• EDATE  and  TDATE  delimiters  serve  to  bracket  a time  frame 
during  which  unit  resource  requirements  and  authorizations  are  valid. 

While  conceivable,  it  is  unlikely  that  a TOE  match  will  not 
occur  where  MTOE  documentation  was  not  found  in  TAADS  or  where  a TAADS 
mismatch  was  "forced."  There  might  be  a case  in  which,  through  error 
omission  or  time  delay,  properly  identified  TOE  documentation  is  not 
resident  within  the  TOE  system  due  to  emergent  operational  requirements 
or  "short-fuse"  action  directed  by  highest  authority.  Except  in  the  most 
unusual  circumstances,  such  a possibility  either  would  not  eventuate  or 
would  be  obviated  through  the  operations  of  SIGMA  to  which  we  have  pre- 
viously alluded. 
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(5)  Detail  Merge.  Detail  merge  does  exactly  what  its  name  implies 
by  merging  the  personnel  and  equipment  lists  obtained  through  the  TAADS 
match  and  TOE  match  processes  into  one  Basic  SACS  Detail  File.  At  this 
point  Basic  SACS  processing  is  complete. 

All  subsequent  divergent  processing  for  PERSACS  or  LOGSACS 
specific  computations  will  employ  the  two  key  files  which  now  effectively 
constitute  the  Basic  SACS  data  base: 

• The  Selected  Units  File 

• The  Basic  SACS  Detail  File 

6.  CONTRIBUTION  TO  SACS 

Basic  SACS  serves  an -integrational  role.  It  is  designed  to  bring 
together  otherwise  separately  maintained  discrete  data  files  into  one 
working  SACS  data  file.  That  data  file  is  the  foundation  upon  which 
PERSACS  and  LOGSACS  processing  may  proceed.  The  fundamental  Basic  SACS 
process  of  unit  match  to  the  manpower  and  equipment  resource  detail 
prescribed  in  DA-approved  TDA,  TOE,  and  MTOE  documents  is  integral  to 
an  elaboration  of  the  personnel  and  equipment  associated  with  those  units 
and  is  precursive  to  all  further  SACS  processing. 

7.  MAJOR  DATA  ELEMENTS 

ACTCO  Action  Code,  the  force  structure  change  to  a unit  on  a given 
date.  A = Activation,  J = Inactivation,  C = Reorganization, 

G = Gain  to  a new  command  assignment. 

ADCON  Administrative  Control  Code,  the  UICCC  of  a headquarters  or 
higher  unit  exercising  administrative  control  over  the  unit. 
AMSCO  Army  Management  Structure  Code,  the  major  fiscal  language  code 
used  for  Army  planning,  programing,  and  budgeting  and  for  the 
Army  budget  presentation  before  Congress.  TOE  units  have  one 
AMSCO  which  is  recorded  in  the  PROFA;  TDA  units  may  have 
multiple  AMSCOs  which  are  recorded  in  the  Manpower  Annex 
file. 

AS GMT  Assignment,  the  major  command  or  DA  staff  agency  to  which  the 

unit  is  assigned. 
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AS  I CO  Additional  Ski 11  Indicator  Code . 

AUBFA  Authorized  Before  Factoring,  if  factoring  of  the  authorized 
strength  is  necessary,  the  AURES  is  moved  to  the  AUBFA  data 
field  and  the  result  of  the  factoring  is  recorded  in  the  AURES 
data  field  thus  preserving  the  original  strength  to  determine 
the  impact  of  factoring  at  a detail  level. 

AU  BO  I Authorization  from  BO IT . 

AUOTR  Authorization  Quantity,  other. 

AURES  Authorized  Structure  Strength. 

AUSHN  Authorization  from  Shorthand  Notes. 

AUSTR  Authorized  Strengths,  includes  AUOFF  (Authorized  Officer), 

AUWOF  (Authorized  Warrant  Officer),  AUENL  (Authorized  Enlisted), 
AUAGR  (Authorized  Military  Aggregate)  and  AUCIV  (Authorized 
Civilian  Aggregate).  Authorized  strength  is  that  portion  of 
the  structure  strength  which  can  be  supported  by  allocated 
manpower. 

AUTAD  TOE  Authorized  TAADS  or  TOE  Strength. 

BRCHP  Branch  of  Service,  Personnel. 

BRNCH  Branch,  an  abbreviation  for  the  branch  of  service  under  which 
a TOE  unit  is  organized. 

CARSS  Combat  Arms  Regimental  System,  the  historical  designation 

assigned  to  combat  and  combat  support  units  of  Infantry,  Armor, 
Field  Artillery  and  Air  Defense  Artillery  TOE  units. 

CATCO  Category  Code,  an  internal  FAS  manipulative  code. 

CCNUM  Command  Control  Number,  the  major  FAS/TAADS-YTAADS  linking  code. 

Identifies  the  command  assignment,  changes,  and  fiscal  year  for 
all  TAADS  documents. 

CIVCN  Civilian  Control  Number,  summary  level  aggregate  of  units  which 

are  applied  against  the  command's  civilian  employment  limitation. 

COMPO  Component  Code,  identifies  the  duty  status  of  the  unit.  1 * 

Active  Army,  2 * National  Guard,  3 ■ Reserve.  4 * Unmanned  Army, 

B « Restructured  Reserves,  C = Mobilization. 

DAMPL  DA  Master  Priority  List,  priority  grouping  of  all  units  or 

activities  for  the  allocation  of  personnel  and/or  equipment. 
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DEPLO 


DPMNT 


DSCMP 


EDATE 


ELSEQ 


EQCON 


ESCON 


FICOD 


FNCAT 


FPLAN 


FORCO 


GRADE 


IDENT 


JCSTY 


LICCO 


Deployment  Package  Assignment , special  unit  mobilization  cate- 


Deplovment  Designation,  indicating  the  deployment  area  and 
month  for  units  scheduled  for  movement  in  the  event  of  general 


war  mobilization. 


Display/Compute  Indicator,  indicates  if  a unit  is  displayed 
for  information  and  computed  (DSCMP  = DC)  or  is  displayed  only 
and  not  computed  (DSCMP  =*  DO)  for  FAS  reports  and  Structure 
and  Composition  System  (SACS)  computations. 

Effective  Date,  the  date  on  which  a unit's  force  structure 


position  becomes  effective. 


Element  Sequence  Number,  sequences  the  subordinate  units  of 


major  units,  e.g.,  battalions  which  are  part  of  a division. 
Equipment  Readiness  Condition  Code,  actual  current  equipment 


readiness  for  deployment. 


Equipment  Serviceability  Condition  Code,  actual  current  equip- 
ment serviceability  for  deployment. 

Force  Identification  Code,  identifies  the  particular  FAS  force 


in  the  multiforce  file. 


Functional  Category,  a FAS  code  used  for  miscellaneous  force 


structure  aggregations. 


Force  Planning  Code,  the  major  FAS  management  language  used  to 


structure  Army  units  and  force  packages.  First  position  indi- 
cates strategic  category:  A = Division  Forces,  B = Special 
Mission  Forces,  C = General  Support  Forces.  Second  position 
displays  force  package  and  the  third  position  displays  loca- 


tion or  orientation. 


Force  Code,  identifies  special  authorization  or  exception  units. 
Grade  of  the  authorized  or  required  position. 

Identity  Code,  designates  the  position  as  officer,  warrant 
officer,  or  enlisted. 


JCS  Unit  Type  Code,  describes  the  type  of  unit  for  which  the 


force  requirement  is  stated. 


Language  Identitv  Code. 


. 


LIN  Line  Item  Number. 

LOCCO  Location  Code,  the  location  at  which  a unit  is  stationed  or  is 
programed  to  be  stationed.  Within  CONUS,  the  code  is  a com- 
bination of  the  Army  area  and  state  abbreviation.  For  over- 
seas locations,  the  code  is  an  abbreviation  of  the  country. 

MATCO  Month  and  Action  Code,  contemplated  deployment  action  for  units 
not  mobilized  until  after  M-Day. 

MBCMD  Mobilization  Command  Assignment,  major  command  or  agency  to 
which  units  are  assigned  after  mobilization. 

MBLOC  Mobilization  Location  Code,  location  of  a unit  on  or  after  M- 

Day;  indicates  the  Army  area  and  state  for  units  in  continental 
locations  and  overseas  abbreviation  for  units  in  theater. 

MBPRD  Mobilization  Period,  indicates  the  appropriate  month  after  M- 
Day  a unit  will  be  activated  or  called  to  active  military 
service. 

MBSTA  Mobilization  Station,  the  current  station  for  CONUS  active 

Army  units;  the  overseas  location  for  Army  Reserve,  National 
Guard,  and  COMPO  C units. 

MGCMD  Major  Command . 

MILCN  Military  Control  Number,  a summary  level  aggregate  of  units 
which  are  applied  against  the  military  strength  portion  of  a 
command's  manpower  ceiling. 

MOS  Military  Occupational  Specialty  Code. 

MTOEC  Modified  Table  of  Organization  and  Equipment  Control  Number,  a 
major  FAS/VTAADS  linking  code  for  TOE  units.  Identifies  the 
first  six  positions  of  unit's  SRCTO,  its  command  assignment, 
and  the  latest  document  change  number.  An  MTOEC  EQ  9999999999 
indicates  that  the  document  is  not  a VTAADS  one. 

NTREF  Note  Reference  Number,  a reference  which  includes  additional 
descriptive  information  for  a unit. 

OPAGY  Operating  Agency  Code,  DA  organizational  element  to  which  funds 
are  allocated  or  sub-allocated. 

OPDAT  Operational  Date,  indicates  the  date  of  unit  assignment  to  the 


force  commitment  on  the  NATO  Defense  Planning  Questionnaire. 


OPSTR  Operating  Strength,  by  officer,  warrant  officer,  enlisted, 
aggregate  military,  and  civilian. 

PECOD  Program  Element  Code,  the  major  DOD  management  language  used 
to  aggregate  units,  manpower,  and  dollars  associated  with  the 
Five  Year  Defense  Program  structure. 

PERMK  Remark  - Personnel. 

PHASE  Phase  Code,  the  authority  for  a unit  record.  PHASE  D or  G 
indicates  that  the  record  is  supported  by  an  approved  TAADS 
document  or  general  order.  Any  other  PHASE  Code  indicates 
that  the  unit  has  an  approved  program  position  not  yet  sup- 
ported by  TAADS  or  a general  order.  M = DA  message  or  letter; 

C =>  Command  originated  change;  A = Approved  Program  Assumption; 

S = DA  Staff  Actions. 

PRCON  Personnel  Readiness  Condition  Code,  actual  current  level  of 
personnel  readiness  of  a unit. 

RCNUM  Record  Control  Number,  1 designates  the  personnel  record  and 
2 the  equipment  record. 

RMKS1  Remarks , applicable  as  further  discriminators  of  MOS  and  posi- 
tion requirements. 

RMKS2  Remarks,  applicable  as  further  discriminators  of  MOS  and  posi- 
tion requirements. 

ROBCO  Readiness  Objective  Code,  for  Active  Army  (COMPO  1)  units,  this 

code  packages  units  according  to  the  light/heavy  corps,  Reforger, 
Airborne  D,  or  2+10  concept.  For  Reserve  and  National  Guard 
units,  this  code  packages  units  according  to  readiness  concepts. 

RQBOI  Requirements  for  BOIP. 

RQOTR  Requirements  for  Quantity  Other. 

RQRES  Required  Structure  Strength. 

RQSHN  Requirements  from  Shorthand  Notes. 

RQTAD  TOE  Required  TAADS  or  TOE  Strength. 

SORCE  Source  of  Data,  TAADS,  TOE,  SHN  or  altered  by  factoring. 

SPLIT  Split  Unit  Indicator,  identifies  those  parent  UICCCs  and  their 
subelements  which  are  located  at  different  command  assignments. 
Additionally,  the  parent  unit  and  the  subelement  must  have 
unique  TAADS  documents. 
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SRCTO  Standard  Requirements  Code,  identifies  the  basic  Table  of 

Organization  and  Equipment  plus  any  variations  for  personnel 
and  equipment  in  a TOE  unit. 

STACO  Station  Code,  the  alphanumeric  code  designating  the  unit's 
geographic  location. 

STNNM  Station  Name,  a meaningful  abbreviation  of  the  unit's  geographic 
location. 

STSTR  Structure  Strengths,  includes  STOFF  (Structure  Officer),  STWOF 
(Structure  Warrant  Officer),  STENL  (Structure  Enlisted),  STAGR 
(Structure  Military  Aggregate),  and  STCIV  (Structure  Civilian 
Aggregate).  For  TOE  units,  structure  strength  is  always  at 
level  1.  For  MTOE  and  TDA  units,  structure  strength  is  indi- 
vidually determined  to  support  the  unit's  requirements. 

* 

TDATE  Transaction  Date,  designates  the  last  Julian  date  on  which  a 
record  was  updated. 

TMCCC  Type  MTOE  (Modified  Table  of  Organization  and  Equipment)  Indi- 
cator, identifies  the  TOE  series  of  the  unit  as  defined  by  its 
TAADS/VTAADS  SRCTO. 

TPSNA  Troop  Program  Sequence  Number,  a code  which  groups  units  accord- 
ing to  their  mission  and  size. 

TRDAY  Transaction  Date,  designates  the  last  Julian  date  on  which  a 
record  was  updated. 

TRCON  Training  Readiness  Condition  Code,  current  level  of  readiness 
condition  based  on  unit  training. 

TYPCO  Type  of  Unit  Code,  identifies  the  basic  organization  of  the 

unit,  1 “ TOE  unit,  2 = TDA  augmentation  to  a TOE  unit,  3 - TDA 
unit. 

UIC  Unit  Identification  Code,  the  alphanumeric  designation  which 

uniquely  identifies  a unit. 

UNCAP  Unit  Capability,  unit  readiness  capability  assigned  by  HQDA 
and  reflected  in  the  TAADS  document. 


This  acronym  is  used  to  designate  transaction  date  and  termination 
date.  Termination  date  is  established  based  on  EDATE  in  the  SACS  unit 
selection  process. 
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UNCLC  Unit  Classification  Code,  aggregates  units  according  to  the 
exact  function  they  perform,  e.g.,  Air  Cavalry  Squadron, 
Neurosurgical  Det,  etc. 

UNCON  Unit  Readiness  Condition,  current  overall  readiness  condition 
of  the  unit.  Incorporates  personnel  and  equipment  readiness 
conditions . 

UNMBR  Unit  Number,  a part  of  the  unit's  description.  For  TOE  units, 
the  UNMBR  is  the  numerical  portion  of  the  unit's  designation. 

TOE  augmentations  carry  the  number  of  the  unit  augmented.  TDA 
units  list  the  first  four  characters  of  the  UICCC  in  this  field. 
UNPID  Unit  Package  Identification  Designator,  identifies  units  in 
specific  force  groupings. 

UNTDS  Unit  Description,  the  narrative  title  of  a unit  which  explains 
its  functional  mission.  UNTDS  is  related  to  a unit's  TPSNA/ 

ELSEQ  and  SRCTO. 

8.  INTERFACE  WITH  OTHER  SYSTEMS 

Basic  SACS  may  be  conceptualized  as  having  pivotal  interface  with 
PERSACS  and  LOGSACS  in  that  its  product,  the  Basic  SACS  Detail  File,  may 
be  used  for  continuance  into  either  PERSACS  or  LOGSACS  processing. 

Basic  SACS  interfaces  with  SIGMA  since  it  assumes  the  selected  forces 
file  generated  by  SIGMA. 

File  interface  internal  to  Basic  SACS  impacts  subsequent  SACS  proces- 
sing with  respect  to  both  unit  and  resource  representation  in  final  SACS 
products.  Optimally,  each  of  the  selected  units  driving  Basic  SACS  should 
be  matched  to  TAADS/TOE  resource  documentation,  thereby  permitting  full 
and  current  unit  and  resource  representation  in  the  PERSACS  or  LOGSACS 
product.  To  the  extent  that  this  is  not  achieved  in  Basic  SACS  processing, 
subsequent  system  outputs  may  contain  distortions  of  resource  data.  In 
the  case  of  PERSACS  outputs,  omissions  of  both  resource  and  unit  structure 
will  also  result  for  units  remaining  unmatched  to  TAADS  or  TOE  documenta- 
tion. 
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1.  SUBSYSTEM/MODEL/DATA  BASE 

a.  Title:  Basis  of  Issue  Plan  (BOIP) 

b.  Status:  Operational 

2.  REFERENCE 

a.  Handout  in  Support  of  USAMSSA  Inter/Intra  Divisional  Briefings, 
Computations  Systems  Branch,  US  Army  Management  Sysetms  Support  Agency 
(USAMSSA),  25-29  June  1973. 

b.  Army  Regulation  71-2,  Basis  of  Issue  Plan,  10  April  1976. 

c.  Interviews  with: 

Mr.  W.  Braswell,  DAMO-RQR 
Mr.  R.  Frank,  USAMSSA 
Mr.  S.  Haupt,  USAMSSA 
Mr.  W.  Collins,  DAMO-FDA 
MAJ  J.  Ionoff,  DAMO-FDA 
MAJ  F.  Anderson,  DAMO-RQA 

3.  STAFF  PROPONENT 

ODCSOPS  (DAMO-RQR) : This  office  exercises  Army  General  Staff  respon- 
sibility for  review,  coordination  and  approval.  The  Training  and  Doctrine 
Command  (TRADOC)  is  charged  with  BOIP  development,  review,  update  and, 
after  DA  approval,  publication. 

4.  COMPUTER  SUPPORT 

a.  Agency:  USAMSSA 

b.  Equipment:  IBM  370/165 

5.  PURPOSE/ROLE 
a.  General 

Army  Regulation  71-2  identifies  three  primary  roles  for  BOIP: 

• To  predict,  early  in  the  materiel  acquisition  cycle,  quantita- 
tive requirements  for  a new  item  of  equipment  to  be  included  in: 

- Tables  of  Organization  and  Equipment  (TOE) 

- Tables  of  Distribution  and  Allowances  (TDA) 

- Common  Tables  of  Allowances  (CTA) 

- Joint  Tables  of  Allowances  (JTA) 

- Additive  Operational  Projects  (AOP) 
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• To  predict  personnel  and  other  equipment  changes  that  may  be 
necessary  In  TOE/TDA/CTA/ JTA/t\OP  in  order  to  accommodate  the  new  item  of 
equipment . 

• To  serve  as  a management  tool  for  use  by: 

- HQDA  to  forecast  new  equipment  densities  for  procurement  pro- 
graming purposes  and  to  identify  resultant  personnel  changes. 

- Combat  development  authorities  in  revising  TOEs. 

- Major  commands  in  revising  TDA  and  other  authorization 
documents  after  type  classification  of  a new  items  of  equipment  (Stan- 
dard LCC-A) . 

Thus,  BOIP  is  designed  to  serve  equipment  and  equipment-related 
personnel  forecast  management  informational  needs.  BOIPs  are  planning 
documents  only,  not  authorization  documents.  Their  use  facilitates  the 
incorporation  in  SACS  computations  of  new  equipment  requirements  and 
authorizations  before  documentation  in  The  Army  Authorization  Documenta- 
tion System  (TAADS)  or  TOE.  The  BOIP  data  base  documents  either  the 
specific  units  by  unit  identification  code  (UIC) , or  types  of  units  by 
Standard  Requirements  Code  (SRC)  that  are  to  receive  the  new  equipment. 
Additionally,  it  details  support  equipment  and  personnel  changes  required 
for  the  new  equipment, 
b.  Specific 

(1)  BOIP  currently  is  utilized  in  LOGSACS  only,  even  though  it 
is  designed  to  serve  as  a basis  for  the  determination  of  new  equipment 
requirements  for  the  programed  and  budgeted  force  as  well  as  new  personnel 
requirements  associated  with  the  new  equipment.  To  date  only  new  equip- 
ment requirements  from  the  BOIP  data  base  have  been  included  in  SACS 
processing.  Where  new  units  must  be  constituted,  BOIP  data  are  incor- 
porated into  Automated  Unit  Reference  Sheet  (AURS) . (See  Appendix  A 

for  a further  discussion  of  AURS.) 

(2)  BOIP  is  composed  of  four  files.  In  order  of  progression  in 
the  life  of  a BOIP,  these  files  are: 

• Process  File  - a BOIP  "holding  area"  used  by  TRADOC  until 
the  particular  BOIP  is  entered  into  In-Process  Files. 

• In-Process  File  - contains  BOIPs  subject  to  modification 
(units  which  are  programed  to  receive  new  equipment) . 
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• Master  File  - contains  BOIPs  in  final  form.  Units  to 
receive  the  new  equipment  are  known  and  recorded. 

• History  File  - contains  old  BOIPs  reflecting  equipment 
that  has  been  type  classified  standard  and  documented  in  other  appro- 
priate publications. 

The  In-Process,  Master,  and  History  Files  contain  the  BOIPs 
from  which  are  selected  those  used  within  a given  LOGSACS  study.  The 
majority  applied  in  LOGSACS  are  derived  from  the  Master  File,  a lesser 
number  from  the  In-Process  File,  with  the  History  File  contributing  less 
than  5 percent. 

(3)  BOIPs  are  developed,  reviewed,  updated  and  coordinated  by 
TRADOC.  ODCSOPS  has  Army  General  Staff  responsibility  for  BOIP  review, 
final  DA  coordination  and  approval.  DA-approved  BOIPs  are  published  by 
TRADOC. 

(4)  Integration  System  Officers  (FISOs)  have  Army  responsibility 
for  specific  items  of  equipment  contained  in  the  BOIP  list.  Preparatory 
to  a LOGSACS  run,  DAMO-RQR  circulates  a listing  among  FISOs  of  all 
approved  In-Process  and  Master  File  BOIPs  formatted  as  in  Figure  D.l. 

The  individual  FISOs  review  the  entire  BOIP  listing  with  particular 
attention  directed  toward  those  equipment  items  for  which  each  FISO  is 
directly  responsible.  In  collaboration  with  DAMO-FDA  analysts,  FISOs 
determine  which  BOIP  listings: 

• Are  still  valid  (since  the  previous  LOGSACS). 

• Had  impact  on  the  previous  LOGSACS. 

• Should  be  applied,  constrained,  or  not  applied  in  the 
present  LOGSACS  computation. 

Upon  completion  of  review  and  recommendations  by  the  several 
FISOs,  DAMO-RQR  consolidates  FISO  recommendations.  The  consolidated 
list  is  forwarded  to  DAMO-FDA  analysts  for  final  review  and  coding. 
Finally,  the  coded  BOIPs  are  submitted  to  USAMSSA  for  application  in 
the  LOGSACS  computation. 
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Figure  D.l.  BOIP  Listing  Format 
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6 . CONTRIBUTION  TO  SACS 

a.  The  primary  contribution  of  BOIP  to  the  SACS  computational  pro- 
cess occurs  in  LOCSACS  processing  ami  accrues  from  its  key  role  in  pro- 
viding a vehicle  to  take  into  account  programed  requirements  for  new 
equipment  items. 

b.  Currently,  BOIP  does  not  contribute  to  PKRSACS.  While  the  BOIP 
file  contains  data  pertaining  to  new  personnel  requirements  associated 
with  new  equipment,  no  PKRSACS  methodology  has  been  developed  to  utilize 
these  data. 


7.  MAJOR  DATA  ELEMENTS 


AD 


AS  I 

ASSOCIATED  BO  I 
PLAN  NUMBER 

ASSOCIATED  LINE 
ITEM  NUMBER 

AVAILABILITY 

DATE 

BO I PLAN 
PROPONENT 

BO  I PS N 
BR 

CLASS 

EST  BO I DATE 

EST [MATED  UNIT 
COST 

GRADE 

JULIAN  DATE 


LIN 


MOS 


Add/ Delete . indicates  whether  MOS  or  secondary  LIN  add 
or  delete  quantity  is  plus  or  minus. 

Additional  Skil  L_  Indicator. 

Associated  Plan  Serial  Number  for  a secondary/associated 

line  item. 

Associated  Line  Item  Number. 

Date  primary  LIN  will  be  available  for  issuance  (for- 
matted as  YYMMDD) . 

Proponent  agency  or_  maj or  eomtmind  which  submitted 
BO I Plan  to  HQ DA. 

BO  I Plan  Ser  I a 1_  Number . 

Branch  within  grade  and  MOS. 

Class  1 f icat ion  of  BO I Plan. 

Estimated  date  by  which  BOI  Plan  will  be  completed 
(formatted  as  YYMMDD). 

Estimated  Unit  Cost  of  Primary  LIN. 

Grade  within  MOS . 

Computer  generated  date  added  to  record  at  time  it  is 
added  to  BOI  data  base. 

Line  I tern  Number . 

Military  Occupational  Specialty . 

Nomenclature  of  the  primary  I IX  for  which,  the  BOI  Plan 
was  developed. 
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ORGANIZATION  Unit  Organ  L.-at  Ion  Peso  rip  tion . 

DESIGNATION 

PEMA  Procurement  ot  Equipment  and  Missiles.  Army,  indicates 

whether  or  not  primary  LIN  is  to  be  procured  as  a PEMA 
1 1 em . 


PREPARATION  PATE 

PRIMARY  LINE 
ITEM  NUMBER 

QUANTITY 

QUANTITY 
CURRENTLY 
IN  TOE 

RCN 


Pate  HOI  Plan  submitted  to  HQDA  (format  tod  as  YYMMPP) . 
LIN  or  primary  item  for  which  BO I Plan  was  developed. 

Quantity  bv  which  BO I Plan  will  affect  MOS  or  LIN. 
Quantity  in  TOE  data  base  as  of  the  change  under  which 
the  Plan  was  drafted. 

Record  Control  Number . commonly  referred  to  as  "Record 
Name . " 


REPLACE  LINE 
ITEM  NUMBER 

SRC 


STANDARP-A  DATE 


l’AAPS 

TDA 

UNIT  COST 


LIN  which  the  pr i maty  BO I LIN  is  to  rep  lac o . 

Standard  Requirements  Code,  same  record  position  is 
occupied  for  SRC,  TPA,  and  AOP  authorizing  equipment 
where  no  TOE,  MTOE,  or  TDA  exists. 

Pate  primary  LIN  will  become  Standard  A (formatted  as 
YYMMDP) . 

The  Army  Author  i .-at  ion  Documents  System,  indicator  to 
show  if  BO I record  has  been  applied  to  TAADS. 

Table  ot  Pist  ribui  ion  and  Allowances. 

Cost  ot  primary  line  Item. 


8.  INTERFACE  WITH  OTHER  SYSTEMS 

B01P  processing  has  interface  with  three  systems,  in  addition  to  its 
use  in  LOC.SACS.  They  are: 

• The  Force  Accounting  System  (FAS) 

• TAADS 

• TOE 

One  application  of  FAS  is  in  the  BOIP  impact  subsystem,  where  a 
report  Is  produced  which  computes  the  cost  of  equipment  and  personnel 
changes  Involved  In  applying  a BOIP  to  a specified  force  during  a par- 
ticular time  frame. 
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The  BOI/TAADS  interface  subsystem  of  BOIP  serves  to  identify  those 
TAADS  documents  affected  by  the  introduction  of  BOIP  items  of  equipment 
into  the  Army  during  a specified  time  frame.  This  process  is  as  follows: 

• BOIP  file  is  matched  to  a specified  FAS  (usually  the  current  year 
force)  In  order  to  create  a complete  listing  of  unit-level  requirement 
changes  imposed  by  BOI. 

• Individual  units  found  on  the  FAS  tile  are  then  located  in  the 
TAADS  data  base  in  order  to  determine  the  impact  of  BOIP  application 
during  a specified  time  interval. 

• Various  reports  are  generated  which  provide  detail  and  summary 
information  extracted  from  the  two  systems. 

TOE  is  used  to  edit  SRCs  in  the  BOIP  update  process  to  ensure 
validity  and  to  compare  TOE  and  BOIP  personnel  and  equipment  detail 
requirements.  The  LIN  edit  file  used  by  TOE  is  also  used  to  check  the 
validity  of  BOIP  transactions. 

Major  data  elements  common  to  BOIP,  FAS,  TAADS , and  TOE  are  shown 
in  the  following  figure. 


System 


Data  Element 


SRC 


UIC 


Grade 


LIN 


MOS 


LIN 

Nomenc lature 


BOIP 


X 


FAS 


TAADS 


!l 


r 


t 
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APPENDIX  E 

EQUIPMENT  STRUCTURE  AND  COMPOSITION  SYSTEM  (LOGSACS) 


1.  SUBSYSTEM/MODEL/DATA  BASE 


a.  Title:  Equipment  Structure  and  Compostion  System  (LOGSACS) 

b.  Status:  Operational 


2.  REFERENCES 

a.  Handout  in  Support  of  USAMSSA  Inter/Intra  Divisional  Briefings, 
25-29  June  1973. 

b.  Program  Formulation  Specification:  ARM05 

c.  Interviews: 

Mr.  W.  Braswell,  DAMO-RQR 
Mr.  R.  Frank,  USAMSSA 
Mr.  S.  Haupt,  USAMSSA 
MAJ  J.  Ionoff,  DAMO-FDA 
Mr.  W.  Collins,  DAMO-FDA 

3.  STAFF  PROPONENT 
ODCSOPS  (DAMO-FDA) 

4.  COMPUTER  SUPPORT 

a.  Agency:  USAMSSA 

b.  Equipment:  IBM  370/65  or  3033 

5.  PURPOSE/ROLE 

a.  The  Equipment  SACS  (LOGSACS)  is  a series  of  computer  programs 
designed  to  support  the  Deputy  Chief  of  Staff  for  Logistics  (DCSLOG) 
and  the  Deputy  Chief  of  Staff  for  Research,  Development  and  Acquisition 
(DCSRDA)  informational  requirements  integral  to  Army  equipment  manage- 
ment functions.  LOGSACS  begins  with  the  Basic  SACS  data  base  and  the 
Selected  Units  File  and  proceeds  to  perform  a range  of  data  refinements; 
such  refinements  being  contingent  upon  the  purpose  and  type  of  SACS  com- 
putation being  run.  LOGSACS  may  be  characterized  as  having  two  distinct 
types  of  computation  which  bear  directly  upon  data  refinement  processing 

• Requirements 

• Authorizations 


A primary  distinction  between  requirements  and  authorizations  is  one  of: 


[ 
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M-Day  Force  needs  at  top  versus 

readiness  level  (AL01) 


Idealized  Requirements  on 
Mobilization  Day  if  war 
should  arise 


Current  Force  needs 
at  less  than  top 
readiness  level 

f 

Actual  Authorizations  for 
use  in  maintenance  of 
a peacetime  force 


LOGSACS  computations  are  the  official  HQDA  record  of  MTOE 
and  TDA  equipment  authorization  data  for  determining  basic  material 
requirements  in  support  of  the  Procurement  of  Equipment  and  Missiles, 
Army  (PEMA)  portion  of  the  Army's  budget.  A Requirement  LOGSACS,  e.g. , 
a Budget  or  Apportionment  Computation,  is  used  to  compute  the  mobili- 
zation day  requirement  of  a peacetime  force  and  typically  computes/dis- 
plays such  a force  at  the  budget  year  and  for  four  additional  years 
beyond  budget  year.  An  Authorization  LOGSACS,  e.g..  The  Army  Equipment 
Distribution  Plan  (TAEDP)  computation,  on  the  other  hand,  is  used  to 
compute  the  equipment  authorizations  for  the  current  force  for  display 
at  the  current  fiscal  quarter  and  projected  to  infinity. 

b.  Refinements  to  the  Basic  SACS  as  performed  through  LOGSACS  pro- 
cessing is  accomplished  by  way  of  five  subsystem  applications: 

• Negative  Suppression 

• Basis  of  Issue  Plans  (BOIP) 

• Shorthand  Notes  (SHN) 

• Air  Armament  (Air  Arm) 

• Tank  Armament  (Tank  Arm) 

Each  of  the  above  subsystems  are  peculiar  to  equipment  SACS  processing 
and  are  described  in  the  following  paragraphs. 

(1)  The  Negative  Suppression  subsystem  of  LOGSACS  is  the  first 
LOGSACS  subsystem  subsequent  to  Basic  SACS'  creation  of  a combined 
TAADS/TOE  Detail  File  and  is  designed  to  programaticallv  suppress  any 
equipment  quantitites  which  contain  a negative  value.  Such  suppression 
of  negative  equipment  values  is  effected  through  replacement  of  all 
minus  quantities  by  zero. 
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Negative  equipment  quantities  may  be  obtained  as  a byproduct  of 
certain  Basic  SACS  and  LOGSACS  processing.  Two  subsystems  identified 
as  having  particular  potential  for  yielding  negative  quantities  of 
equipment  are: 

• SRC  Assembly  (in  Basic  SACS  processing) 

• Shorthand  Notes  (in  LOGSACS  processing) 

Negative  quantities  may,  in  certain  instances,  be  the  outcome  of: 
Combining  (assembling)  augmenting  TOEs  (identified  by  SRC)  from  the 
FAS  Notes  File  where  a preponderance  of  minus  (-)  signed  SRCs  occur 
relative  to  Basic  SACS  data  base  quantities. 

Examp le : 


Basic  SACS  Data  Base 


UIC 

WABCAA 

WABCHA 


EDATE  SRC 

760630  07045H000 

790630  07045H00Q 


Notes  File 


UIC  EDATE  SRC  TIMES  SIGN 

WABCAA  790630  07047H000  200 


In  this  case,  a clerical  error  (200  should  have  been  002)  would  cause  an 
Infantry  Battalion  to  lose  200  Rifle  Companies  from  its  requirement  on 
790630  generating  a net  result  of  negative  equipment  quantities.  Nega- 
tive suppression  is  always  applied  after  SRC  assembly  to  set  such  nega- 
tive quantities  to  zero. 

Application  of  Shorthand  Notes  to  delete  X number  of  specific 
equipment  quantities  in  a given  unit  on  dates  for  which  no  such  equip- 
ment is  resident  in  that  unit.  Net  result  is  negative  equipment  quan- 
tities. Negative  Suppression  is  always  applied  after  SHN  application 
to  set  such  negative  quantities  to  zero.  Note  that  when  multiple  SHN 


applications  occur  in  a given  LOGSACS  run,  each  SHN  application  is 
followed  by  Negative  Suppression. 

(2)  Basis  of  Issue  Plan  (BOIP).  During  the  TAADS  and  TOE  Match 
subsystem  of  Basic  SACS  equipment  authorizations  are  obtained  for  each 
unit  in  the  selected  force.  The  TAADS  and  TOE  documents  used  to  develop 
equipment  authorizations  may  or  may  not  have  taken  into  account  require- 
ments and  authorizations  for  new  equipment  items  scheduled  to  become 
available  in  future  years.  Information  about  such  new  equipment  is  con- 
tained in  the  BOIP  File. 

In  its  role  to  provide  current  information  regarding  changes 
in  personnel  and  equipment  requirements  due  to  initial  issuance  of  new 
or  improved  equipment  items  in  the  Army,  BOIP: 

• Modifies  the  equipment  authorizations  given  in  TAADS  and 
TOE  to  account  for  plans  to  issue  new  equipment. 

• Contains  appropriate  new  personnel  requirements  associated 
with  the  new  equipment.  (NOTE:  Currently,  BOIP  is  not  used  in  PERSACS 
computations  to  determine  force  personnel  requirements) 

• Includes  the  estimated  cost  of  line  items  of  equipment. 
(Therefore,  the  cost  of  equipment  changes  involved  in  applying  a BOIP 
to  a specified  force  during  a particular  time  frame  can  be  computed. 

• Automatically  updates  the  LOGSACS  authorized  equipment 
quantities  and  LIN. 

Application  of  discrete  BOIPs  to  a given  LOGSACS  computation 
is  user  specified.  SACS  allows  ODCSOPS  (DAMO-FDA  in  conjunction  with 
DAMO-RQR)  to  constrain  the  application  of  these  BOIP  to  certain  types 
of  units,  to  units  in  certain  areas  of  the  world,  to  units  of  a specific 
component,  or  to  other  strategic  elements.  The  BOIP  Identifies  through 
either  a specific  unit  identification  (the  UIC  of  a unit),  or  through  a 
SRC  (TOE  document  number),  which  units  are  to  receive  the  new  equipment 
items  in  SACS.  The  BOIP  file  also  identifies  what  support  equipment 
changes  are  required  for  the  new  equipment,  what  old  equipment  is  to  be 
replaced,  and  what  the  specific  personnel  requirements  associated  with 
the  new  equipment  will  be.  BOIP  is  presented  in  greater  detail  in  the 
BOIP  appendix  D. 
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(3)  Shorthand  Note  (SHN)  System  is  designed  to  facilitate  chang- 
ing equipment  quantities  within  the  LOGSACS  environment  through: 

• Add, 

• Delete,  or 

• Change 

SHN  application  does  not  impact  LOGSACS  input  files.  Only  output  is 
affected.  Thus  if,  for  example,  a units'  tank  authorization  quantity 
is  required  to  be  increased  by  a factor  of  two  via  SHN,  such  increase 
is  reflected  in  only  the  present  LOGSACS  output.  That  is,  future  LOGSACS 
computations  for  this  particular  unit  will  require  similar  SHN  increment 
(X2)  in  order  to  provide  its  full  tank  requirement  (this  assumes  that  no 
document  updating  activities  have  occurred  in  the  interval). 

The  Shorthand  Notes  application  is  brought  to  bear  under 
"last  minute"  change  conditions  to  effect  a more  accurate  LOGSACS.  Such 
"last  minute"  change  conditions  obtain  when  it  is  necessary  to: 

• Substitute  for  a BOIP  when  time  or  circumstances  do  not 


permit  use  of  the  BOIP  system. 

• Incorporate  decisions  concerning  new  equipment  into  SACS 
when  other  systems  are  untimely. 

• Provide  a temporary  correction  of  SACS  output  data. 

Shorthand  Notes  are  written  to  modify  quantities  of  equip- 
ment in  particular  units.  Equipment  quantities  are  adjusted  either  by 
adding  to  existing  quantities  or  by  changing  the  existing  quantity  with 
a new  figure. 

The  Shorthand  Notes  process  consists  of  a single  Master  file. 
The  SHN  Master  File  is  resident  on  magnetic  tape  and  is  maintained  by 
DAMO-FDA  Equipment  Analysts.  The  Shorthand  Notes  are  aggregated  into 
batches,  with  similar  types  of  equipment  usually  in  particular  batches. 
When  the  equipment  analysts  write  the  Shorthand  Notes  they  identify 
which  notes  apply  to  a particular  SACS  computation.  Within  a given 
Note,  the  analyst  has  the  capability  of  changing  any  of  all  of  the 
following  elements:  LIN,  SRC,  UIC,  required  quantity,  authorized  quan- 
tity, or  any  of  the  constraining  information  (e.g.,  EDATE,  TDATE,  COMPO, 
AS GMT,  FPLAN , LOCCO,  TPSN,  STATUS,  USAGE). 
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The  Shorthand  Note  System  is  a powerful  tool  in  that  it 
facilitates  override  of  equipment  quantities  specified  by  TAADS,  TOE  or 
BOIP . In  the  original  design  of  the  SHN  system,  SHN  application  was 
the  very  last  step  in  the  LOGSACS  process,  i.e.,  the  "fine  tuning"  of 
the  LOGSACS.  However,  subsequent  to  initial  implementation  of  the  SHN 
system,  processes  specifically  addressing  Aircraft  and  Tank  Armament 
have  been  appended  to  LOGSACS  necessitating  further  SHN  "fine  tuning" 
applications. 

(A)  The  Air  Armament  (Air  Arm)  is  a process  designed  to  calculate 
the  number  of  armaments  packages,  e.g. , machine  guns,  necessary  to  sup- 
port certain  helicopters.  Air  Arm  objective  is  to  insure  that  each  unit 
identified  as  requiring  helicopter  armaments  is  given  exactly  the  number 
of  armament  systems  it  should  have.  Fixed  ratios  have  been  defined  so 
that,  based  on  the  number  of  helicopters  that  a unit  has,  it  will  receive 
a certain  number  of  armament  systems.  For  example,  the  following  are 
Aricraft  LlNs  and  their  associated  Armament  LINs  and  the  ratio  used  by 
the  Air  Arm  program  to  compute  the  quantities  given  to  the  Aircraft  LINs: 

AIRCRAFT  LIN:  233490 

I II  III 

ARMAMENT  LINs  generated:  A90123,  A90344,  L92260 

Ratio  used  to  compute  the  ARMAMENT  LIN  quantities  follow: 

I.  Ratio:  1 ARMAMENT  LIN  A90123  generated  for  1 AIRDRAFT  LIN  233490 
II.  1 ARMAMENT  LIN  A90344  generated  for  4 AIRCRAFT  LIN  233490 
Thus : 


Aircraft  > 

Z33490 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

Armament > 

A90344 

1 

1 

1 

1 

2 

2 

2 

3 

3 

3 
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III.  Ratio: 


21/4  ARMAMENT  LINs  L92260  generated  for  1 AIRCRAFT  LIN  233490 


Thus : 


Aircraft  — ► 

* 

Armament  * 


Z33490 

1 

2 

3 

4 

5 

5 

5 

8 

9 

10 

11 

12 

L92260 

3 

5 

7 

9 

12 

14 

16 

18 

21 

23 

25 

23 

* 

Note:  Because  of  the  physical  characteristics  of  each  of  the  ARMAMENT 
LINs,  fractions  or  remainders  after  computations  are  made 
are  determined  by  Army  Staff  user  and  in  most  cases  do  not 
follow  any  mathematical  logic  such  as  "round  up"  or  "round 
down." 


Air  Arm  processing  begins  with  the  SACS  detail  file.  The 
detail  file  remains  unchanged,  except  for  those  armaments  LINs  and  heli- 
copter LINs  which  have  been  specified  by  the  user.  Air  Armaments  which 
are  user-designated  to  be  controlled  via  Air  Arm  ratio-computational 
processing  follow  a two-step  process  wherein: 

• Step  1:  Whenever  the  user-designated  helicopter  armament 
LIN  is  encountered  in  the  detail  file,  the  record  is  deleted  from  the 
detail  and  written  (unchanged)  to  a smaller  output  file  for  possible 
future  reference.  New  detail  records  for  these  LINs  are  generated  in 
the  next  step. 

• Step  2:  New  armament  records  are  created  on  the  basis  of 
user-prescribed  ratio  of  Armament  LINs  per  Aricraft  LIN.  New  armament 
records  are  given  the  SRC  and  EDATE-TDATE  spread  of  their  associated 
helicopter  and  are  merged  into  the  SACS  detail  file. 

Air  Arm  processing  thus  facilitates  the  analyst's  prescrip- 
tion of  an  Armament-to-Aircraf t ratio  schedule  for  certain  specified 
helicopter  armaments. 

(5)  The  Tank  Armament  (Tank  Arm)  subsystem  is  very  similar  to 
Air  Arm  in  objective  and  processing.  Tank  Arm,  however,  has  recently 
met  with  several  processing  problems  of  a programmatic  nature  which 
have  resulted  in  its  being  held  in  application  suspense  until  such  time 
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as  program  difficulties  are  remedied.  Presently,  Tank  Armament  adjust- 
ments are  effected  through  application  of  Shorthand  Notes. 

When  Armaments  processing  is  complete,  application  of  SHN 
batches  of  lesser  magnitude  then  the  initial  LOGSACS  SUN  (5-6  batches 
versus  50-60  batches)  is  available  for  equipment  analyst  use.  Such 
minor  "fine  tuning"  is  normally  available  whenever  computational  manipu- 
lations have  impai c of  an  interactional  nature  on  other  equipments. 

Upon  completion  of  minor  SHN  processing.  Negative  Suppression 
is  invoked  as  a final  measure  to  ensure  the  non-occurrence  of  negative 
equipment  quantities.  Following  Negative  Suppression  the  LOGSACS  is 
prepared  for  report  generation. 

The  primary  analytic  report  produced  by  the  equipment  SACS 
is  the  "LIN  Summary."  This  report  shows  the  required  and  authorized 
quantities  for  each  equipment  item  in  the  LOGSACS  computation  for  six 
fiscal  years.  Each  of  the  previously  described  subsystems  in  the  Equip- 
ment SACS  also  produces  a series  of  reports  displaying  what  transpired 
in  that  particular  subsystem.  Such  reports  are  helpful  to  SACS  analysts 
in  maintaining  an  audit  trail  through  the  SACS  computational  cycle. 

6.  CONTRIBUTIONS  TO  SACS 

LOGSACS  contributes  the  principal  SACS  product  for  the  Logisti- 
cians of  the  ARSTAF  and  field  activities.  LOGSACS  encompasses  equipment 
requirements  and  authorizations  at  the  UIC  level  of  detail.  This  overall 
equipment  requirement  and  authorizations  data  support  (1)  functions  of 
programming  and  budgetting  of  resources  and  (2)  functions  of  procurement 
and  distribution  of  items  of  equipment. 


1.  SUBSYSTEM/MODEL/DATA 

a.  Title:  Force  Accounting  System  (FAS) 

b.  Status:  Operational 

2.  REFERENCES 

a.  AR  1-1,  Planning,  Programing,  and  Budgeting  within  the  Department 
o £ the  Army , 25  May  1976. 

b.  Force  Accounting  System  User's  Guide,  March  1976. 

c.  CSR  18-11,  Force  Development  Management  Information  System, 

18  February  1976. 

d.  Interviews: 


LTC  A. 

Taylor,  ODCSOPS 

(DAMO-FDA) 

Ms. 

T. 

Fasick,  ODCSOPS 

(DAMO-FDA) 

Ms. 

R. 

Baker,  ODCSOPS 

(DAMO-FDA) 

Mr. 

C. 

Danford,  USAMSSA  (ACAM-SDD-C) 

Ms. 

V. 

Hughes,  USAMSSA 

(ACAM-SDD-C) 

3.  STAFF  PROPONENT 
ODCSOPS  (DAMO-FDA) 

4.  COMPUTER  SUPPORT 

a.  Agency:  USAMSSA  (ACAM-SDD-C) 

b.  Equipment:  IBM  370/165  or  3033 

5.  PURPOSE/ROLE 

a.  FAS  provides  the  Army  Staff  with  an  automated  means  of  maintaining 
the  Master  (M)  and  other  forces  at  the  UIC  level  of  detail  and  the  capa- 
bility to  access  such  unit  data  for  Active  Army,  Army  Reserve,  Army 
National  Guard,  and  mobilization  units  rapidly.  It  is  a major  subsystem 
of  the  Force  Development  Management  Information  System  (FDMIS),  and  is 
used  as  a comprehensive  data  base  to  support  all  phases  of  the  Army 
Planning,  Programing,  and  Budgeting  System. 

b.  FAS  is  composed  of  several  files,  the  Forces  File  (PROFA) , 

Notes  File  (NOTFA) , and  Manpower  Annex  (MANX). 
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(1)  Forces  File.  The  FROFA  is  the  main  file  of  FAS.  It  is  a 
multiple  forces  file  and  contains  the  Master  Force  as  well  as  additional 
work  or  notional  forces.  The  Master  Force,  also  known  as  the  M Force, 
is  the  force  from  which  planning,  programming,  and  budgeting  force  struc- 
ture data  are  extracted.  The  M Force  contains  manpower  requirements  and 
authorizations  as  reflected  in  Program  Budget  Guidance  (PBG) , Command 
Plans,  and  other  planning  and  programing  documents  from  the  current  date 
through  the  budget  year  plus  5 years.  Work  or  notional  forces  can  be 
created  to  support  other  force  structuring  requirements  and  studies. 

Each  force  contains  units  of  at  least  one  of  the  following 
six  components  (COMPO) : 


COMPO  1 
COMPO  2 
COMPO  3 
COMPO  4 


COMPO  B 
COMPO  C 


Active  Army 
National  Guard 
Army  Reserve 

Unmanned  Units  - identifies  TOE  units  which  contain 
equipment  pool  but  no  personnel.  These  units  are 
used  in  budget  and  apportionment  computations  for 
the  procurement  of  equipment.  FAS  contains  only 
basic  force  structure  and  manpower  information;  it 
contains  no  equipment  requirements  or  authorizations . 
Active  National  Guard 


Active  Ai 


Reserve 


(2)  Notes  File.  The  NOTFA  is  used  to  record  multiple  Standard 
Requirements  Codes  (SRCs)  for  Modified  Table  of  Organization  and  Equip- 
ment (MTOE)  units.  This  is  necessary  because  the  PROFA  File  can  only 
display  one  SRC  per  record  and  the  NOTFA  must  be  used  to  account  for 
multiple  SRCs.  Note  SRCs  are  used  for  units  not  supported  by  a TAADS 
(The  Army  Authorizations  Documents  System)  document  in  order  to  ensure 
that  personnel  and  equipment  requirements  are  correctly  defined.  Note 
SRCs  can  be  used  either  to  add  or  subtract  requirements  to  the  matching 
PROFA  record  for  MTOE  units.  The  NOTFA  interfaces  only  with  PROFA. 

(3)  Manpower  Annex.  The  MANX  was  created  to  maintain  manpower 
requirements  and  authorizations  by  Army  Management  Structure  Code  (AMSCO) 
and  Program  Element  Code  (PECOD)  for  those  Table  of  Distribution  and 


Allowance  (TDA)  units  that  are  allocated  resources  from  multiple  AMSCO 
sources.  Also,  the  MANX  file  maintains  civilian  strengths  by  identity, 
whereas  the  PROFA  file  malntulns  only  civilian  aggregate  strengths.  Only 
Active  Army  TDA  and  TDA  augmentation  units  may  have  MANX  data  since  MTOE 
units  are  allocated  resources  from  only  one  AMSCO  source, 
c.  The  objectives  of  FAS  are  to: 

(1)  Manage  an  accurate  file  of  current,  programed,  and  planned 
units  within  the  Army's  force  structure. 

(2)  Provide  a data  base  from  which  current  or  projected  authori- 
zation or  organization  data  for  a specific  unit,  or  grouping  of  units, 
can  be  retrieved  for  analysis. 

(3)  Provide  managers  and  staff  at  HQDA  with  timely  and  accurate 
management  information  pertaining  to  units  or  grouping  of  units  in  the 
current,  programed,  or  planned  force  structure  of  the  Army. 

(A)  Provide  HQDA  with  the  official  Army  Master  Force  (M  Force) 
Program  per  AR  1-1. 

(5)  Aid  in  maintaining  unit-level  accountability  for  Army  mili- 
tary and  civilian  manpower  authorizations  at  AMSCO/PECOD  level  of  detail. 

(6)  Account  for  all  parent  Unit  Identification  Codes  (UICs). 

(7)  Reflect  the  latest  force  structure  and  manpower  guidance  from 
Congress,  OSD,  and  HQDA  that  has  been  issued  to  the  field. 

(8)  Express  the  force  structure  in  traditional  force  development 
languages  as  well  as  in  financial  management  languages. 

(9)  Define  planning  force  structures  under  the  Total  Army  Concept. 

(10)  Provide  input  to  various  force  development  models. 

(11)  Interface  with  other  Array  resource  management  information 
systems. 

6.  CONTRIBUTION  TO  SACS 

a.  The  first  thing  done  in  any  SACS  computation  is  to  copy  the  M 
Force  for  study.  This  is  initiated  by  0DCS0PS (DAMO-FDA)  providing 
force  selection  criteria  which  identify  the  force  components  (Active 
Army,  Army  Reserve*  etc.),  type  units  (MTOE,  TDA),  and  time  periods 
selected  for  study.  The  FAS  data  base  provides  SACS  with  unit  information 
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needed  to  Identify  units  being  studied,  and  the  programed  manpower  aggre- 
gations for  chose  units  at  the  projected  EDATE  of  the  SACS  computaiton. 

b.  The  file  of  units  selected  from  FAS  during  the  selection  process 
is  called  the  Selected  Units  File  and  is  the  principal  input  file  to  a 
SACS  computation,  since  the  strengths  and  units  present  in  FAS  are  the 
basis  for  PERSACS  and  LOGSACS  controls. 

7.  MAJOR  DATA  ELEMENTS 

FAS  contains  about  85  data  elements;  the  following  list  contains  the 
major  ones: 

ACTCO  Action  Code,  the  force  structure  change  to  a unit  on  a given 
date.  A ■ Activation,  J • Inactivation,  C • Reorganization, 

C - Gain  to  a new  conmiand  assignment. 

ADCON  Administrative  Control  Code,  the  UIC  of  a headquarters  or  unit 
that  exercises  higher  headquarters  administrative  control. 

AMSCO  Army  Management  Structure  Code,  a standard  classification  of 
Army  activities  and  functions  used  for  planning,  programing, 
budgeting,  and  resource  accounting.  MTOE  units  have  one  AMSCO 
which  is  recorded  in  the  PROFA;  TDA  units  may  have  multiple 
AMSCOs  which  are  recorded  in  the  Manpower  Annex  file. 

ASGMT  Assignment,  the  major  command  or  DA  staff  agency  to  which  the 
unit  is  assigned. 

AUSTR  Authorized  Strengths,  Includes  AUOFF  (Authorized  Officer), 

AUWOF  (Authorized  Warrant  Officer),  AUENL  (Authorized  Enlisted), 
AUAGR  (Authorized  Military  Aggregate) , AUUSD  (Authorized  US 
Direct  Hire),  AUFND  (Authorized  Foreign  National  Direct  Hire), 
AUIDH  (Authorized  Indirect  Hire),  and  AUCIV  (Authorized 
Civilian  Aggregate).  Authorized  strength  is  that  portion  of 
the  structure  strength  which  can  be  supported  by  allocated 
manpower . 

AUTHR  Authority,  the  document  or  guidance  authorizing  the  unit's 
force  structure  position. 

BRNCH  Branch,  the  branch  of  service  of  a unit. 
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CCNUM 

COMNT 

COMPO 

DAMPL 

DEPLO 

DPMNT 

DSCMP 

EDATE 

ELSEQ 

EQCON 

ESC  ON 

FI  COD 

FINOT 


Combat  Arms  Regimental  System,  the  historical  designation 
assigned  to  combat  and  combat  support  units  of  Infantry, 

Armor,  Field  Artillery,  and  Air  Defense  Artillery  TOE  units. 
Command  Control  Number,  the  major  FAS/TAADS-VTAADS  linking 
code.  Identifies  the  command  assignment,  changes,  and  fiscal 
year  for  all  TAADS  document. 

Component  Code  for  the  Notes  File,  the  FAS  COMPO  containing 
the  Note  SRCTO(s). 

Component  Code,  identifies  the  component  and  component  duty 
status  of  the  unit.  1 ■ Active  Army,  2 ■ National  Guard, 

3 ■ Army  Reserve,  4 ■ Unmanned  Army,  B ■ Active  National  Guard, 
C ■ Active  Army  Reserve. 

DA  Master  Priority  List,  priority  assigned  to  a unit  for  the 
allocation  of  personnel  and/or  equipment. 

Deployment  Package  Assignment,  special  unit  mobilization  cate- 
gory. 

Deployment  Designation,  indicates  the  deployment  area  and  month 
for  units  scheduled  for  movement  in  the  event  of  general  war 
mobilization. 

Display/Compute  Indicator,  indicates  if  a unit  is  displayed 
for  information  and  computed  (DSCMP  ■ DC)  or  is  displayed  only 
and  not  computed  (DSCMP  ■ DO)  for  FAS  reports  and  Structure 
and  Composition  System  (SACS)  computations. 

Effective  Date,  the  date  on  which  a unit's  force  structure 
position  becomes  effective. 

Element  Sequence  Number,  sequences  the  subordinate  units  of 
major  units,  e.g.,  battalions  which  are  part  of  a division. 
Equipment  Readiness  Condition  Code,  actual  current  equipment 
readiness  for  deployment. 

Equipment  Serviceability  Condition  Code,  actual  current  equip- 
ment serviceability  for  deployment. 

Force  Identification  Code,  identifies  the  particular  FAS  force 
in  the  multiforce  file. 

Force  Code  for  the  Notes  File,  the  FAS  force  containing  the 
Note  SRCTO(s) . 
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FPLAN  Force  Planning  Code,  the  major  FAS  management  language  used  to 
structure  Army  units  and  force  packages.  First  position  indi- 
cates strategic  category:  A ■ Division  Forces,  B - Special 
Mission  Forces,  C ■ General  Support  Forces.  Second  position 
displays  force  package  and  tne  third  position  displays  location 
or  orientation. 

JCSTY  JCS  Unit  Type  Code,  describes  the  type  of  unit  for  which  the 
force  requirement  is  stated. 

LOCCO  Location  Code,  the  location  at  which  a unit  is  stationed  or  is 

programed  to  be  stationed.  Within  CONUS,  the  code  is  a combina- 
tion of  the  Army  area  and  state  abbreviation.  For  overseas 
locations,  the  code  is  an  abbreviation  of  the  country. 

MACTO  Month  and  Action  Code,  contemplated  deployment  action  for  units 
not  mobilized  until  after  M-Day. 

MBCMD  Mobilization  Command  Assignment,  major  command  or  agency  to  which 
units  are  assigned  after  mobilization. 

MBLOC  Mobilization  Location  Code,  location  of  a unit  on  or  after  M-Day; 

indicates  the  Army  area  and  state  for  units  in  continental  loca- 
tions and  overseas  abbreviation  for  units  in  theater. 

MBPRD  Mobilization  Period,  indicates  the  appropriate  month  (after  M- 
Day)  a unit  will  be  activated  or  called  to  active  military 
service. 

MBSTA  Mobilization  Station,  the  current  station  for  CONUS  active  Army 
units;  the  overseas  location  for  Army  Reserve,  National  Guard, 
and  COMPO  6 units. 

MTOEC  Modified  Table  of  Organization  and  Equipment  Control  Number,  a 
major  FAS/VTAADS  linking  code  for  MTOE  units.  Identifies  the 
first  six  positions  of  unit's  SRCTO,  its  command  assignment, 
and  the  latest  document  change  number.  An  MTOEC  EQ  9999999999 
indicates  that  the  document  is  not  VTAADS. 

NEDAT  Effective  Date  for  the  Notes  File,  the  FAS  EDATE  containing  the 
Note  SRCTO (s) . 

NTSRC  Notes  File  Standard  Requirements  Code. 

NUMBR  The  number  of  times  a single  Notes  File  Standard  Requirements 

Code  is  computed  within  its  UICCC. 
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PECOD 

PHASE 


PRCON 

ROB  CO 

SPLIT 

SRCTO 

STACO 

STATS 


Operating  Agency  Code,  DA  organizational  element  *"o  which 
funds  are  allocated  or  suballocated. 

Program  Element  Code,  the  major  DOD  management  language  used 
to  aggregate  units,  manpower,  and  dollars  associated  with  the 
Five  Year  Defense  Program  structure. 

Phase  Code,  the  authority  for  a unit  record.  PHASE  D or  G 
indicates  that  the  record  is  supported  by  an  approved  TAADS 
document  or  general  order.  Any  other  PHASE  Code  Indicates 
that  the  unit  has  an  approved  program  position  not  yet  sup- 
ported by  TAADS  or  a general  order.  M ■ DA  message  or  letter; 
C =*  Command  originated  change;  A * Approved  Program  Assump- 
tion; S • DA  Staff  Actions. 

Personnel  Readiness  Condition  Code,  actual  current  level  of 
personnel  readiness  of  a unit. 

Readiness  Objective  Code,  for  Active  Army  (COMPO  1)  units, 
this  code  packages  units  according  to  the  light/heavy  corps, 
Reforger,  Airborne  D,  or  other  concept  for  Army  Reserve  and 
National  Guard  units.  This  code  packages  units  according  to 
readiness  concepts. 

Split  Unit  Indicator,  identifies  those  parent  UICCCs  and  their 
sub-elements  which  are  located  at  different  command  assign- 
ments. Additionally,  the  parent  unit  and  the  sub-element 
must  have  unique  TAADS  documents. 

Standard  Requirements  Code,  identifies  the  basic  Table  of 
Organization  and  Equipment  plus  any  variations  for  personnel 
and  equipment  in  a TOE  unit. 

Station  Code,  the  alphanumeric  code  designating  the  unit's 
geographic  location. 

Status  Code,  classifies  the  status  of  Active  Army  STRAF  units 
by  the  state  of  readiness  for  use  in  specific  missions  or 
activities.  Other  units  may  be  classified  as  CONUS  Operating 
(CO),  Theater  (TH) , Reimbursable  (RM) , Special  Foreign  Activi- 
ties (FA),  Exception  Units  (CE) , or  Deployable  (DI). 
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STNNM  Station  Name,  a meaningful  abbreviation  of  the  unit's  geographic 
location. 

STSTR  Structure  Strengths,  includes  STOFF  (Structure  Officer),  STWOF 
(Structure  Warrant  Officer),  STENL  (Structure  Enlisted),  STAGR 
(Structure  Military  Aggregate),  and  STCIV  (Structure  Civilian 
^Rregate).  For  MTOE  units,  structure  strength  is  always  at 
level  1.  For  TDA  units,  structure  strength  is  individually 

determined  to  support  the  unit's  "requirements." 

* 

TDATE  Transaction  Date,  designates  the  last  Julian  date  on  which  a 
record  was  updated. 

TMCCC  Type  >fTOE  (Modified  Table  of  Organization  and  Equipment) 

Indicator,  identifies  the  TOE  series  of  the  unit  as  defined 
by  its  TAADS/VTAADS  SRCTO. 

TPSNA  Troop  Program  Sequence  Number,  a code  which  groups  units 
according  to  their  mission  and  size. 

TRCON  Training  Readiness  Condition  Code,  current  level  of  readiness 
condition  based  on  unit  training. 

TYPOO  Type  of  Unit  Code,  identifies  the  basic  organization  of  the 
unit,  1 ■ TOE  unit,  2 » TDA  augmentation  to  a TOE  unit,  3 ■ 

TDA  unit. 

UICCC  Unit  Identification  Code,  the  alphanumeric  designation  which 
uniquely  identifies  a unit. 

UIC3JT  Unit  Identification  Code  for  the  Notes  File,  the  FAS  UICCC 
containing  the  Note  SRCTO(s). 

UNCAP  Unit  Capability,  unit  readiness  capability  assigned  by  HQDA 
and  reflected  in  the  TAADS  document. 

UNC1C  Unit  Classification  Code,  aggregates  units  according  to  the 
exact  function  they  perform,  e.g..  Air  Cavalrv  Squadron, 
Neurosurgical  Det,  etc. 

- . 

This  acronym  is  used  to  designate  transaction  date  and  termination  date. 

Termination  date  is  established  based  on  EDATE  in  the  SACS  unit  selection 

process.  For  purposes  of  this  report,  transaction  date  will  be  TRDAY . 


UNTDA 


Unit  Readiness  Condition,  current  overall  readiness  condition 
of  the  unit.  Incorporates  personnel  and  equipment  readiness 
condition. 

Unit  Number,  a part  of  the  unit's  description.  For  MTOE  units 
the  UNMBR  is  the  numerical  portion  of  the  unit's  designation. 
TDA  augmentations  carry  the  number  of  the  unit  augmented. 

TDA  units  list  the  first  four  characters  of  the  UICCC  in 
this  field. 

Unit  Description,  the  narrative  title  of  a unit  which  explains 
its  functional  mission.  UNTDA  is  related  to  a unit's  TPSNA/ 
ELSEQ  and  SRCTO. 


8.  INTERFACE  WITH  OTHER  SYSTEMS 

a.  The  Army  Authorization  Document  System  (TAADS) , is  the  major 
interfacing  system.  HQDA  Detail  TAADS  is  now  a part  of  FORDIMS  and  is 
called  the  Authorizations  Subsystem  (AS).  HQDA  Summary  TAADS  is  not  yet 
a part  of  FORDIMS  but  is  derived  by  summarizing  AS  data.  On  a monthly 
basis  (see  AUTS,  Appendix  B)  FAS  records  (M  Force)  are  updated  with  in- 
formation from  approved  TAADS  documents.  These  data  replace  assumption 
or  command  plan  data  previously  reflected  in  FAS  for  the  specific  unit. 
The  major  linking  data  elements  common  to  FAS  and  TAADS  are: 

• UICC 

• EDATE 

• CCNUM 

• MTOEC 

• SRCTO 

• AMS CO 

• STSTR 


• AUSTR 

b.  The  Structure  and  Composition  System  depends  on  FAS  to  provide 
the  M Force  structure  for  its  computations.  SACS  interfaces  FAS,  TAADS, 
TOE,  BOIP,  and  the  Shorthand  Notes  System  (SHN).  By  combining  these 
data  sources,  SACS  computes  force  structure  personnel  and  equipment 
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Units  File  which  contains  controlling  unit  reference  data  and  the  pro- 
gramed unit  authorized  strength. 

c.  FAS  is  interfaced  with  the  Army  Force  Program  (AFP)  through  the 
WILCON*  report.  FAS  manpower  authorizations  (allocations)  for  the  units 
of  a given  command  must  not  exceed  the  total  allocations  for  that  consnand 
as  reflected  in  AFP  for  the  end  of  each  fiscal  year.  The  WILCON  report 
provides  force  managers  with  such  a comparison  of  data  in  these  systems. 

d.  Vertical  Force  Accounting  System  (VFAS)  is  the  major  commands' 
(MACOM)  version  of  the  DA  FAS.  It  provides  selected  Army  commands  with 
their  units'  data  in  an  automated  force  development  data  base  for  inter- 
nal command  purposes.  Its  use  accelerates  information  flows  between  the 
field  and  DA.  VFAS  has  the  same  data  elements  as  FAS.  FAS  and  VFAS  data 
tapes  are  exchanged  between  HQDA  and  the  major  commands  that  utilize  VFAS. 

e.  FAS  has  interface  (manual  and  automated)  with  several  other 
systems  that  are  not  discussed  in  this  document  since  they  do  not  directly 
involve  SACS. 


WILCON  is  an  original  acronym  combining  abbreviations  of  the  word 
"control"  and  the  name  of  an  original  requester. 


r. 

i 

i 

r 

[ 

L 

i 

r 


i 


I 


l 


i. 


r 

1. 


1.  SUBSYSTEM/MODEL/PATA  BASE 

a.  Title:  Personnel  Structure  and  Composition  System  (PERSACS) 

b.  Status:  Operational 

2.  REFERENCES 

a.  Handout  in  Support  of  USAMSSA  Inter/Intra  Divisional  Briefing  > 
25-29  June  1973. 

b.  A Study  of  Army  Data  Bases  for  Personnel  Authorizations  and 
Assets.  Volume  1 - Main  Report,  GRC  Report  OAD-CR-70,  Nov  1974. 


c.  Interviews: 

Mr. 

R. 

M.  Walden 

, USAMSSA 

Mr. 

S. 

D.  Haupt, 

USAMSSA 

Mr. 

C. 

B.  Joyce, 

USAMSSA 

3.  STAFF  PROPONENT 
ODSCOPS (D AMO- FDA) 

4.  COMPUTER  SUPPORT 

a.  Agency:  USAMSSA  (ACAM-SDD-C) 

b.  Equipment:  IBM  370/165  or  3033 

5.  PURPOSE/ROLE 
a.  General 

PERSACS  is  a series  of  computer  programs  that  are  designed  to 
provide  the  Army  General  Staff  (ARSTAF)  with  personnel  requirements  and 
authorizations  information  to  support  the  functions  of  recruitment, 
training,  distribution,  etc.  PERSACS  is  supportive  of  these  management 
functions  in  its  role  of  providing  the  Army  Personnel  System  with  require- 
ments and  authorizations  by  MILID  (i.e..  Officer,  Warrant  Officer  and 
Enlisted)  and  by  grade,  branch.  Military  Occupational  Specialty  (MOS) , 
and  Remarks  for  all  authorized  positions  in  Army-wide  units  included  in 
the  user-specified  force.  To  the  extent  that  PERSACS  is  successful  in 
meeting  such  informational  requirements,  it  is  of  major  contributive  value 
in  supporting  the  Army's  objective  of  placing  a trained  soldier  (a  face) 
in  every  authorized  position  (a  space)  Army-wide. 
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b.  Specific 

(1)  The  PERSACS  computation  requires  the  availability  of  two  key 
files,  namely: 

• The  Selected  Units  File  (extracted  from  the  P Force 
which  reflects  the  SIGMA  corrective  process), 

• The  Basic  SACS  Detail  File  (a  merged  file  of  TAADS  and 
TOE  requirements  and  authorizations  detail  representing 
the  units  selected  for  SACS  study). 

(2)  PERSACS  is  a three-stage  refinement  adjustment  process, 
applied  to  the  Basic  SACS  Detail  File,  of: 

• Remarks  Adjustment, 

• Interface,  and 

• Factoring. 

When  these  refinements  are  completed,  the  PERSACS  is  distributed  to  the 
ARSTAF  for  further  processing  with  respect  to  personnel  related  functions. 
The  refinement  processes  are  explained  in  the  following  subparagraphs. 

c.  Remarks  Adjustment 

The  rationale  and  purpose  of  the  remarks  adjustment  routine  is 
to  ensure  that  PERSACS  reflects  the  best  data  possible.  TAADS  and  FAS 
do  not  contain  identical  data  element  structures.  Each  system  has  some 
data  that  differs  from  the  other.  The  remarks  data  element  is  one  such 
element.  Remarks  are  contained  only  within  the  TAADS  data  base. 

The  Remarks  Adjustment  ensure  that  documented  TAADS  remarks  apply 
to  TOE  information,  when  both  TAADS  and  TOE  provide  unit  detail  data  for 
different  EDATES.  Unit  information  from  the  FAS  is  "time  oriented"  based 
on  its  EDATE  and  while  a given  unit  may  at  time  1 receive  its  authoriza- 
tions from  TAADS,  at  time  2 it  may  receive  from  TOE,  and  at  time  3 again 
from  TAADS.  When  a unit  is  to  receive  its  authorizations  from  TAADS, 
(e.g.,  time  1)  its  record  in  TAADS  data  base  carries  the  data  element 
"Remarks";  whereas,  when  the  unit  is  to  receive  its  authorizations  from 
TOE  (e.g.,  time  2),  its  record  in  the  TOE  data  base  will  not  carry  the 
"Remarks"  field.  Thus,  in  those  instances  when  a unit  receives  TOE 
detail  information  and  TAADS  detail  information,  as  in  the  above  example, 
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the  "remarks"  field  does  not  automatically  carry  over  from  TAADS  to  TOE. 
This  circumstance  requires  that  the  TAADS  remarks  be  projected  to  TOE 
via  the  remarks  adjustment  process. 

The  TOE’s  lack  of  a remarks  field  is  particularly  relevant  to  a 
PERSACS.  Specifically,  the  remarks  field  carries  qualifying  information 
for  certain  personnel  positions;  such  qualifying  information  is  over  and 
above  what  is  reflected  by  the  grade,  branch,  and  MOS.  For  example,  a 
remark  code  could  indicate  peculiar  qualifications  such  as  tracked 
vehicles  qualified,  special  weapon  qualified,  male  or  female.  Remarks 
adjustment  essentially  involve  holding  as  constant  the  percentage  dis- 
tribution of  all  authorizations  with  peculiar  qualifications  as  reflected 
by  the  remarks  field  under  TAADS-to-TOE  transitional  conditions  as 
described  above.  Thus,  if  TAADS  shows  a Remarks  Quant ity/Percentage 
distribution  for  a given  unit  of 


Remark 

9±1 

1 

01 

10 

10 

02 

05 

5 

Projection  Key 

03 

50 

50 

04 

35 

35 

Total 

100 

but  the  TOE  counterpart  to 

this  TAADS 

shows  only  an  aggregated  authoriza 

tion  quantity  of  80  (i.e.. 

100-80  = 20  fewer  than  TAADS)  then  the  TAADS 

percentages  distribution  would  be  projected  into  the  TOE  thusly: 

Remark 

Z 

01 

8 

10 

02 

4 

Projection  Key 

03 

40 

50  Remains  Constant 

04 

28 

35 

Total 

80 

Remark  characteristics  are 

thus  made 

to  project  from  TAADS  into  TOE  in 

direct  proportion  to  their 

occurrence 

within  TAADS  document,  resulting 

in  a scaled-up  or  scaled-down  version  of  particular  qualifying  remark 
quantities  in  the  TOE  document. 
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Upon  completion  of  Remarks  Adjustment  processing,  TOE  elements 
of : 

UIC  Grade  Branch  MOS  Remark  1 

will  be  expanded  from  a single  TOE  aggregated  line  for  a given  unit  to  be 
identical  to  TAADS  multiple  detail  lines  for  the  unit,  albeit  to  scaled- 
up  or  -down  quantities,  as  shown  above. 

d . Interface 

Interface  is  a PERSACS  program  designed  to  "interface"  the 
Selected  Units  File  for,  the  current  PERSACS  study,  with  the  detail  file 
derived  from  the  basic  SACS  processing.  Through  the  interfacing  process 
to  match  unit  file  to  detail  file,  a determination  is  made  of  those  units 
having  no  documents.  If,  at  this  point  in  PERSACS  processing,  a unit  is 
undocumented,  the  Interface  program  will  drop  the  unit  from  the  unit  file 
and  it  will  not  be  reflected  in  PERSACS  computational  results. 

Those  units  dropped  in  the  Interface  process  were  previously 
identified  with  the  SIGMA  process  as  being  undocumented.  With  respect  to 
PERSACS  processing  SIGMA  presented  the  earliest  and  only  opportunity  to 
identify  and  correct  such  problem  units.  If  an  undocumented  unit  passes 
SIGMA  processing  and  SRC  information  is  carried  on  the  unit,  then  TOE 
requirements  data  may  permit  basic  SACS  processing  to  continue  the  unit 
through  PERSACS  processing.  TDA  units  carry  no  SRC  data  and  are,  conse- 
quently, destined  to  "No  Compute"  status  in  PERSACS  unless  rectified  in 
SIGMA  processing.  Given  no  TAADS  and  no  TOE  authorization  documents,  the 
unit  at  interface  processing  is  dropped  from  the  final  refinement/ 
adjustment  processing  of  PERSACS. 

e.  Factoring 

Factoring  is  a process  used  in  PERSACS  to  reconcile  TAADS  docu- 
ments pertaning  to  MILID  authorized  quantities  (Officer,  Warrant  Officer, 
Enlisted)  with  the  FAS  selected  unit ' a personnel  authorizations  for  the 
SACS  under  study.  Such  reconciliation  is  performed  by  individual  units 
and  is,  in  essence,  a scaling  up  or  down  of  HQDA  approved  TAADS  or  TOE 
detail  documented  quantifies  to  conform  to  FAS  authorizations  reflected 
in  the  selected  units  file.  Factoring  adjusts  only  authorized  strengths; 
adjustment  to  required  strengths  are  not  addressed  in  the  factoring 
procedure. 


In  the  SIGMA  process,  a user  option  permits  the  determination  of 
the  number  of  selected  units  (from  FAS)  having  personnel  quantities  vary- 
ing by  more  than  a user-specified  percentage  from  their  respective  HQDA 
approved  strength.  Such  a role  within  the  SIGMA  process,  referred  to  as 
the  "Percentage  Factoring"  option,  indicated  the  number  of  cases  which 
ragiht  warrant  special  user  attention  or  Intervention.  Since,  for  example, 
a departure  between  a given  unit's  personnel  quantities  and  respective 
TAACS  personnel  quantities  requiring  more  than  7002  factoring,  tends  to 
suggest  an  unusual  discrepancy  which  may  be  the  result  of  clerical  error 
or  an  otherwise  inadvertent  change  to  the  unit's  data  in  the  FAS  file. 

In  its  role  of  "pre-processor"  to  basic  SACS,  SIGMA  is  intended  to  serve 
to  identify  these  units  that  require  Inordinate  factoring  in  PERSACS, 
and  provides  the  facility  for  correcting  such  disparities.  No  actual 
factoring  computations,  to  bring  TAADS  or  TOE  Personnel  strengths  into 
consonance  with  the  selected  unit  record  (from  FAS),  is  done  in  SIGMA. 

Such  computations  are  the  sole  domain  of  the  Factoring  module — the  final 
step  in  the  production  of  PERSACS. 

The  mechanics  and  iterative  nature  of  Factoring  are  straight- 
forward and  may  best  be  elucidated  through  an  example: 

Given:  1.  A unit  record  (selected  from  FAS  for  this  PERSACS) 

shows  the  unit  to  be  authorized  100  officers. 

2.  Respective  TAADS  detail  for  the  same  unit  reflects 
authorization  of  4 different  types  of  officers  at 
the  branch  and  MOS  level  for  a total  of  only  90 
officers. 


FAS  authorization 
Officers  (in  aggregate) 
Strength  Total  100 


TAADS  authorization 
Officers  (in  detail) 


low  grade 


high  grade 


lZ£e 


Strength 


90  strength  total 


10% 

disparity 

Thus,  on  factoring  iteration  1 (FI1)  total  authorized  strengths  of  the 


FAS  aggregate 

(100) 


versus 


TAADS  detail 


yield  an  initial  computed  disparity  of  10%,  i.e.. 


100-90 


by  which 


TAADS  strengths  will  begin,  via  the  factoring  objective  process,  to  be 
adjusted  toward  FAS  strength  specification  in  accordance  with  the 
following  schedule: 

• The  lowest  grade  with  the  highest  strength  (officer  type  #2 
in  the  above  example)  will  be  the  subject  of  the  FI1  factor- 
ing adjustment.  This  strength  is  factored  up  or  down  by 
the  computed  disparity  percentage  to  yield  the  strength 
value  by  which  the  given  officer  type  is  to  be  adjusted. 

The  adjusting  strength  value,  if  fractional,  is  rounded 
to  the  nearest  integer  value. 

• The  adjusting  strength  delta  (signed  integer  + or  -) 
computed  above  is  summed  into  the  strength  listed  for 
the  above  grade. 

• The  impact  on  strength  total  effected  by  the  above 
delta  is  determined  by  summing  all  strengths  for 
grades  subject  to  factoring.  If  the  newly  derived 
strength  total  is  not  yet  identical  to  FAS  strength. 
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then  the  next  lowest  grade  with  the  next  highest  strength 
will  be  factored  as  per  the  above  factoring  procedure. 


o Factoring  Iterations  continue  until  a newly  derived  strength 
total  across  personnel  types  equates  to  FAS  aggregate 
strength.  This  may  involve  a great  number  of  factoring 
iterations. 

The  above  example,  using  TAADS  detail  officer  strength  of  90  with  a require- 
ment to  factor  all  officer  grades  to  an  aggregate  FAS  strength  of  100, 
is  illustrated  in  figure  G.l.  The  arithmetic  and  iterative  processing 
involved  to  effect  a 10Z  increment  in  strength  is  not  insignificant. 

Thus,  as  shown  in  the  discusson  and  figure  G.l,  factoring  is 
designed  to  make  larger  changes  in  the  lower  grades  with  the  higher 
density  MOSs  and  branches.  The  reasoning  behind  this  is  that  such 
changes  will  have  less  impact  on  the  unit's  ability  to  perform  its  mission. 
Also,  there  is  less  training  time  associated  with  low  grades  and  high 
population  MOSs  than  with  high  grade,  high  skill  positions.  Hence,  lower 
grade  authorizations  can  be  more  readily  restored  if  this  becomes  neces- 
sary. 

Certain  restrictions  are  observed  within  the  factoring  process 
including: 

• A recognition  that  certain  key  jobs  (e.g.,  aviators, 
doctors,  etc.)  should  not  be  eliminated,  i.e.,  factored 

to  zero,  even  when  authorized  strength  is  reduced  consider- 
ably. 

• The  exclusion  from  factoring  of  the  highest  officer  and 
enlisted  grades,  e.g.,  general  officers  and  sergeant 
ma j or  s . 


* 

s 

« 


A provision  within  factoring  generally  avoids  the  reduction 
to  zero  of  authorizations  for  any  grade  and  MOS  or  grade 
and  branch.  The  objective  is  to  not  factor  to  zero  until 
all  authorization  lines  for  that  military  ID  have  been 
reduced  to  a value  of  one. 
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Figure  G.l.  Example:  Factoring  Iterations  (FI) 
Required  to  Adjust  Officer  Strengths 
of  a TAADS  Document  up  to  10% 


Factoring,  in  PERSACS  processing,  is  a major  contributor  to  the 
high  incidences  of  discrepancy  between  TAADS  and  PERSACS.  By  virtue  of 
the  current  practice  to  factor  TAADS  documented  authorizations  up  or 
down  to  match  FAS  strengths,  variation  between  the  TAADS  and  SACS 
strengths  will  exit.  In  this  connection,  an  additional  SACS  peculiar 
processing  practice  contributing  to  differences  between  TAADS  and  SACS 
authorizations  files  is  the  SACS  utilization  of  TOEs  as  substitute 
authorizations  documents  for  units  that  lack  TAADS  documents  or  where 
forced  TAADS  mismatched  conditions  are  created. 

When  PERSACS  factoring  is  complete,  all  unit  strengths  (MILID 
aggregates  from  FAS)  will  be  in  agreement  with  unit  strengths  by  MILID 
within  the  unit's  detail  for  record  extracted  from  TAADS  or  TOE. 

After  the  Remarks,  Interface,  and  Factoring  routines  are  completed, 
the  PERSACS  becomes  a reporting  system.  A series  of  reports  at  the 
grade,  branch,  MOS,  and  type  personnel  levels  are  produced  which  indicate 
the  contents  of  the  PERSACS.  A copy  of  the  PERSACS  type  is  provided  to 
MILPERCEN. 

6.  CONTRIBUTION  TO  SACS 

The  PERSACS  is  one  of  the  principal  SACS  products.  In  this 
respect,  it  contributes  to  the  ARSTAF  and  field  activities  principal 
requirement  and  authorization  data  at  the  UIC  level  of  detail. 

7.  MAJOR  DATA  ELEMENTS 

Data  elements  are  listed  in  the  Basic  SACS  description  at 
Appendix  C.  Therefore,  they  are  not  repeated  here. 

8.  INTERFACE  WITH  OTHER  SYSTEMS 

The  PERSACS  product  has  no  interface  with  ODCSOPS  systems,  other 
than  PAAS,  the  Personnel  Authorizations  Analysis  System.  The  principal 
user  is  the  Military  Personnel  Center  (MILPERCEN),  where  PERSACS  data 
are  used  in  systems  relating  to  recruiting,  training,  distribution,  etc. 


1.  SUBSYSTEM/MODEL/DATA  BASE 

a.  Title:  Shorthand  Note  (SHN)  System 

b.  Status:  Operational 
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2.  REFERENCES 

a.  Handout  in  Support  of  USAMSSA  Inter/Intra  Divisional  Briefings , 
25-29  June  1973. 

b.  Structure  and  Composition  System  (SACS)  User's  Guide,  USAMSSA, 
Undated. 

c.  LOGSACS  (SHN  SUBSYSTEM),  USAMSSA  DPR  PH-0410-77,  15  April  77. 

d.  Interviews  with: 

Major  J.  Ionoff,  ODCSOPS  (DAMO-FDA) 

Major  R.  L.  Meredith,  ODCSOPS  (DAMO-FDA) 

Mr.  W.  Collins,  ODCSOPS  (DAMO-FDA) 

Mr.  S.  D.  Haupt,  USAMSSA 
Mr.  R.  Frank,  USAMSSA 

3.  STAFF  PROPONENT 
ODCSOPS  (DAMO-FDA) 

4.  COMPUTER  SUPPORT 

a.  Agency:  USAMSSA 

b.  Hardware:  IBM  370/165 

5.  PURPOSE/ROLE 

a.  SHN  currently  is  a LOGSACS  subsystem  only.  It  permits  the  ARSTAF 
to  add,  change,  or  delete  equipment  and  related  quantities  during  a 
LOGSACS  computation.  Shorthand  Notes  are  used  for: 

• Correcting  errors  which  may  be  in  "authorization"  data 

input  to  LOGSACS.  Such  correctons  are  immediately  reflected 
in  LOGSACS  data. 

e Substituting  for  a Basis  of  Issue  Plan  (BOIP)  when  time  or 
circumstances  do  not  permit  use  of  BOIP. 

e Incorporating  last  minute  equipment  authorization  decisions. 
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Shorthand  notes  affect  quantities  of  equipment  in  particular  units. 

Units  can  be  identified  specifically  by  unit  identification  code  (UIC), 
or  by  type  of  unit  using  the  standard  requirements  code  (SRC-the  TOE 
document  number).  It  is  Important  to  note  that  shorthand  notes  are  used 
as  a means  of  changing  the  LOGSACS  output  only  - they  do  not  change  the 
contributing  data  base  (TAADS,TOE,  BOIP). 

b.  Shorthand  notes  are  contained  within  a single  Master  File  and 
are  grouped  into  batches  which  contain  similar  items  of  equipment.  New 
SUN  are  updated  to  this  file.  The  SACS  Equipment  Analysts  are  responsible 
for  developing  the  SHN,  maintaining  the  SHN  File,  and  identifying  which 
notes  are  to  be  applied  during  each  LOGSACS  computation.  The  SHN  File 
resides  on  magnetic  tape  which  is  maintained  in  USAMSSA. 

c.  SHN  transactions  and  their  uses  are: 

(1)  The  add  transaction  is  the  most  frequently  used  and  serves 
two  purposes: 

• To  add  new  shorthand  notes  to  the  SHN  File  either  by 
creation  of  a new  SHN  batch  or  by  adding  to  an  existing 
SHN  batch. 

• To  replace  existing  notes  in  the  SHN  File. 

The  add  transaction  is  matched  to  the  SHN  File  on  the  following  elements: 

• Batch  Number  - a seven  position  alphanumeric  used  for 
information  and  retrieval  purposes  including  analyst 
code.  Standard  Study  Number  (SSN)  being  analyzed  and 
sequence  number  assigned  by  the  analyst. 

• Line  Item  Number  (LIN)  of  the  equipment  item  to  be 
adjusted. 

• S or  U - S indicates  that  the  SHN  is  to  be  written  at 
the  generalized  level  of  SRC;  U indicates  that  the  SHN 
will  affect  a specific  unit. 

• Component  Code  (COMPO) 

• Assignment  Code  (ASGMT) 

• Force  Planning  Code  (FPLAN) 

• SRC 
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o urc 

o Location  Code  (LOCCO) 

o Troop  Program  Sequence  Number  (TPSN) 

When  these  elements  are  matched  to  the  SHN  File,  the  add  transaction  data 
will  replace  the  existing  SHN  File  record.  If  a match  is  not  found,  then 
the  add  transaction  data  is  appropriately  inserted  in  the  SHN  File  and  a 
sequence  number  is  automatically  assigned  to  the  note  by  the  update  system. 
Each  note  in  each  batch  is  assigned  a sequence  number  when  it  is  entered 
into  the  SHN  File. 

(2)  The  change  transaction  is  used  to  change  one  or  more  fields 
in  one  or  more  notes  in  an  existing  batch  on  the  SHN  File.  The  analyst 
has  the  capability  of  changing  any  or  all  of  the  following  elements:  LIN, 
SRC,  UIC,  required  quantity,  authorized  quantity,  or  any  of  the  con- 
straining information  (e.g.,  EDATE,  TDATE , COMPO,  ASGMT,  FPLAN , LOCCO, 

TPSN,  STATUS,  USAGE).  The  change  transaction  is  matched  on  sequence 
numbers. 

(3)  The  delete  transaction  is  used  to  delete  an  entire  SHN  batch 
or  portion  of  a batch  from  the  SHN  File  where  the  SHN  batch  number 
specified  corresponds  to  an  existing  batch  in  the  file.  SHN  do  not  delete 
LIN  from  LOGSACS.  LIN  quantities  may  be  reduced  to  zero  but  the  LIN  will 
still  be  present.  If  the  required  and  authorized  quantities  are  both 
zero,  the  LIN  will  not  be  printed  on  the  LIN  Summary  Report  (see  LOGSACS 
appendix),  but  will  appear  in  an  SHN  impact  report.  SHN  processes  will 
not  delete  (through  subtracting)  quantities  below  a zero  quantity. 

(4)  The  copy  transaction  is  used  to  copy  an  existing  batch  from 
the  SHN  File  and,  in  the  process  assign  a new  batch  number  to  the  copied 
notes.  The  original  batch  is  not  changed  in  any  way. 

d.  The  shorthand  note  application  in  LOGSACS  is  a four  step  operation 
which,  in  order  of  occurrence,  includes: 

o Develop  data  and  code  SHN  transaction  forms, 
o USAMSSA  prepares  punched  cards. 

o USAMSSA  processes  punched  cards  to  update  the  SHN  File, 

o USAMSSA  applies  SHN  batches  listed  in  the  Data  Process- 

ing Request  (DPR)  to  the  LOGSACS  detail  file. 
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Following  is  an  example  of  a shorthand  note  application  to  LOGSACS. 
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Shorthand  Note  File 


NOTE  1 

WABBAA 

(UIC) 

Helicopter  +1 

NOTE  2 

07015 

(SRC) 

Tank  2 

SAC 

Equipment 

File 

UIC 

SRC 

Equip . Item 

Previous  Qty  New  Qty 

WABBAA 

01005 

Helicopter 

4 5 (NOTE  1) 

WACCAA 

07015 

Tank 

5 2 (NOTE  2) 

WADDAA 

05010 

Tank 

5 5 (No  change) 

In  the  example,  NOTE  1 in  the  SHN  Master  File  contains  an  addition  trans- 
action type  note  for  WABBAA  which  will  add  1 helicopter  to  whatever 
quantity  the  unit  presently  has.  NOTE  2 is  also  an  addition  transaction 
of  the  replacement  note  type,  which  is  to  be  applied  to  all  units  of  a 
certain  type.  The  type  of  unit  is  identified  by  SRC  code,  in  this  case 
07015.  This  note  will  give  these  types  of  units  two  tanks  regardless 
of  what  they  originally  had.  The  impact  of  these  two  notes  on  the  SACS 
equipment  file  is  shown.  We  see  that  the  first  note  adds  +1  to  WABBAA 
authorizations  for  helicopters,  giving  a new  quantity  of  5.  The  second 
note,  because  its  SRC  matched  that  of  WACCAA,  replaced  a quantity  of  5 
with  a requirement  of  two  tanks.  WADDAA  remains  unaffected  because  it 
does  not  match  the  shorthand  note  file  on  either  UIC  or  SRC. 

The  shortland  notes  system  is  a powerful  tool  in  that  it  provides 
the  capability  to  override  equipment  authorizations  specified  by  TAADS , 
TOE,  or  BOIP  systems.  The  decision  to  apply  SHN  to  SACS  ultimately 
rests  with  the  SACS  Branch  Equipment  Analyst.  It  is  his/her  judicious 
and  proper  usage  of  this  "fine  tuning"  mechanism  that  benefits  the  accu- 
racy of  LOGSACS. 

6.  CONTRIBUTION  TO  SACS 

Current  SHN  processing  is  applicable  to  LOGSACS  only.  SHN 
permit  adjustments  in  LIN  and  quantity  in  the  LOGSACS  output.  One  of 
the  more  significant  SHN  contributions  to  LOGSACS  is  providing  LIN 
data  to  FAS  TDA  units  that  are  unmatched  to  TAADS.  Unlike  PERSACS, 
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where  authorizations  are  not  computed  on  unmatched  FAS  units,  the  LOGSACS 
Equipment  Analysts  can  determine  what  equipment  is  required  for  particular 
TDA  units  and,  through  SHN,  LIN  detail  data  can  be  added  to  the  LOGSACS 
products. 


7.  MAJOR  DATA  ELEMENTS 


AS  GMT 


B/N 


COMPO 


FPLAN 


LIN 


LOCCO 


S or  U 


SRC 


TPSN 


Assignment , the  major  command  or  DA  staff  agency  to 
which  the  unit  is  assigned. 

Branch  Number,  a seven  position  alphanumeric  code  used 
for  information  retrieval  purposes.  It  includes 
analyst  code.  Standard  Study  Number  (SSN) , and  sequence 
number . 

Component  Code,  identifies  the  component  to  which  the 
unit  is  assigned.  1 = Active  Army,  2 = National  Guard, 

3 » Army  Reserve,  4 = Unmanned  Army,  etc. 

Force  Planning  Code,  the  major  FAS  management  language 
used  to  structure  Army  units  and  force  packages.  First 
position  indicates  strategic  category:  A » Division 
Forces,  B = Special  Mission  Forces,  C » General  Support 
Forces.  Second  position  indicates  force  package  and 
the  third  position  indicates  location  or  orientation. 

Line  Item  Number,  is  the  specific  equipment  identifica- 
tion. 

Location  Code,  the  location  at  which  a unit  is  stationed 
or  is  programed  to  be  stationed.  Within  CONUS,  the 
code  is  a combination  of  the  Army  area  and  state  abbre- 
viation. For  overseas  areas,  it  is  the  country  code. 

SHN  field  wherein  S indicate  that  the  SHN  is  to  be  writ- 
ten at  the  generalized  level  of  SRC,  and  U indicates  that 
the  SHN  will  affect  a specific  unit. 

Standard  Requirements  Code,  identifies  the  basic  Table 
of  Organization  and  Equipment  plus  any  variations  for 
personnel  and  equipment  in  a TOE  unit. 

Troop  Program  Sequence  Number,  a code  which  groups  units 
according  to  their  mission  and  size. 
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Unit  Identification  Code,  the  alphanumeric  designation 
which  uniquely  identifies  a unit. 


8.  INTERFACE  WITH  OTHER  SYSTEMS 

The  only  system  that  SHN  interfaces  with  is  LOGSACS.  This  inter- 
face permits  the  LOCSAC.S  Equipment  Analyst  to  add  to,  delete  from,  or 
change  equipment  quantities  in  specified  type  units  throughout  the  force 
or  one  particular  unit.  This  facilitates  the  incorporation  of  last 
minute  adjustments  in  the  LOGSACS  output  without  necessitating  complete 
reruns  of  the  process. 
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1 . SYSTEM /MODEL /DATA  BASE 

a.  Title:  SACS  Information  Gathering  and  Management  Analysis 
(SIGMA)  System 

b.  Status:  Operational 

2 . REFERENCES 

a.  SIGMA  Users1  Guide,  US  Army  Management  Systems  Support  Agency 
(USAMSSA),  March  1978. 

b . Handout  in  Support  of  USAMSSA  Inter/Intra  Divisional  Briefing , 
25-29  June  1973. 

c.  Interviews: 

Ms.  M.  Randall,  D AMO- FDA 
MAJ  R.  Meredith,  D AMO- FDA 
MAJ  J.  lonoff,  D AMO- FDA 
Mr.  R.  Walden,  USAMSSA 
Mr.  C.  Joyce,  USAMSSA 
Mr.  S.  Haupt,  USAMSSA 

3.  STAFF  PROPONENT 
ODCSOPS 

4 . COMPUTER  SUPPORT 

a.  Agency:  USAMSSA 

b.  Equipment:  IBM  370/165 

5.  PURPOSE/ROLE 
a.  General 

SIGMA  is  a SACS  exogenous  process  employed  as  a SACS  pre-pro- 
cessing to: 

• Accept  any  specified  force  selected  from  the  Force  Accounting 
ing  System  (FAS)  for  SACS  study. 

• Expeditiously  identify  apparent  errors  and  inconsistencies 
between  selected  force  unit  structure  and  manpower  aggregations  in  the 
Army  Force  Program  as  reflected  in  FAS,  and  the  unit  structure  and 
manpower  detail  contained  in  The  Army  Authorisation  Documents  System 
(TAADS)  and  the  Table  of  Organization  and  Equipment  (TOE)  system. 
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• Afford  a cathode  ray  tube  (CRT)  means  of  on-line  correction 
of  confirmed  errors  and  Inconsistencies,  assuring  that  every  possible 
unit  in  the  selected  force  unit  file  is  matched  to  either: 

- Valid  Table  of  Distribution  and  Allowances  (TDA)  documenta- 
tion or  Modified  Table  of  Organization  and  Equipment  (MTOE)  documenta- 
tion in  TAADS,  or 

- Scandard  TOE  documentation  in  the  TOE  file  in  the  case  of 
MTOE  units  for  which  no  valid  TAADS  documentation  is  available. 

• Achieve  a near  error-free  interface  between  FAS,  TAADS,  and 
TOE  data  bases. 

SIGMA  emulates  Basic  SACS  logic  (see  Basic  SACS,  Appendix  C) 
to  complete  the  unit  match  process  and  assess  the  percentage  magnitudes 
of  adjustment  which  will  be  required  to  bring  TAADS/TOE  selected  unit 
manpower  detail  to  FAS  program  level  aggregations.  However,  SACS  steps 
not  essential  to  attain  unit  match/manpower  adjustment  SIGMA  objectives 
are  not  replicated,  thus  greatly  accelerating  the  SIGMA  process, 
b.  Specific 

Before  SIGMA  may  be  called  upon  to  perform  its  role  to  prepare 
a force  for  structuring  and  computation,  three  data  bases  must  be  con- 
currently "frozen": 

• FAS,  specifically  the  Master  (M)  Force  and  the  Notes  File. 

• TAADS,  specifically  TAADS  Header  with  Detail  Summary  (strength! 

Files . 

• TOE,  specifically  the  TOE  Header  with  Detail  Summary  (strength) 

files. 

FAS  contributes  an  exact  copy  of  the  M Force  to  the  SIGMA  pro- 
cess. The  M Force  copy  is  from  FAS  disk  medium  to  tape  using  a USAMSSA 
utility  program  and  effectively  "freezing"  the  copied  force,  which  is 
then  redesignated  the  Q Force.  The  Q Force  is  the  common  force  file 
from  which  SIGMA,  based  upon  the  Data  Processing  Request  (OPR)  selection 
criteria,  will  extract: 

• A P Force  for  use  within  a PERSACS  computation,  or 

• An  L Fotce  for  use  within  a LOGSACS  computation. 


i 


I 

t 


1-3 


Upon  SIGMA's  P or  L Force  selection,  the  force  will  reside  in 
its  designated  area  on  disk.  TAADS  and  TOE  document  data  bases  are 
copies  and  frozen  in  like  manner. 

SIGMA  performs  sufficient  SACS-emulating  processing  in  its  pre- 
SACS  utilization  to  permit  identification  and  correction  of  inconsisten- 
cies/incompatibilities between  SACS-integral  data  bases.  These  deficien- 
cies would  not  otherwise  be  identified  until  Basic  SACS  detail  processing 
exposed  interface  failure  between  the  TAADS,  FAS,  and  TOE  data  bases  when 
united  within  a SACS  environment.  Absent  SIGMA,  resolution  of  interface 
deficiencies  exposed  in  Basic  SACS  would,  effectively,  require  new  start 
and  re-run  of  the  time  consuming  Basic  SACS  detail  processing.  Using 
SIGMA: 

• The  selected  force  is  overlayed  with  current  TAADS  document 
numbers  as  a means  of  providing  each  constituent  unit  a key  element  to 
select  detail  document  records  for  computation  within  a SACS  environment. 
The  association  of  a selected  unit  with  a TAADS  document  earmarks  that 
unit  to  receive  its  authorizations  from  TAADS. 

• Those  units  not  having  a TAADS  document  number  will: 

- Either  be  associated  with  a TOE  document  via  a standard 
requirements  code  (SRC)  and  receive  their  authorizations  from  that  TOE 
document;  or 

- Be  dropped  from  the  force  in  the  ensuing  SACS  computation, 
in  the  event  a match  to  TAADS  or  TOE  documentation  is  not  effected 
through  intercession  of  Command  or  Force  Managers  in  successive  SIGMA 
iterations . 

• Interface  deficiencies  are  expeditiously  exposed;  and  resolu- 
tion within  the  SIGMA  process  is  facilitated  by  a conversational  tele- 
processing characteristic  of  the  system  (via  CRT)  which  permits  on-line 
corrections/updates  to  the  selected  units.  The  major  sources  of 
inconsistency/incompatibility  identified  as  deficiencies  for  correction 
through  the  SIGMA  process  derive  from: 

- The  failure  of  selected  force  units  to  be  paired  with  appro- 
priate resource  documentation  from  TAADS  or  TOE,  as  outlined  above. 
Causative  factors  vary  from  initial  use  of  incorrect  unit  identification 
through  nonavailability  of  approved  resource  documentation.  SIGMA  edit 
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procedures  isolate  and  allow  addressal  of  mismatches,  producing  reports 
affording  SIGMA  users  the  opportunity  to  take  on-line  corrective  measures 
insuring  force-to-resource  documentation  interface  compatibility. 

- Isolation  through  the  SIGMA  percentage  factoring  option  of 
those  units  having  TAADS/TOE  personnel  strength  quantities  which  depart 
markedly  from  unit  strengths  reflected  in  force  data  copies  from  FAS. 
Aberrant  data  are,  thus,  flagged  and  managers  are  effectively  afforded 
advance  notice  in  time  to  verify  or  correct  the  data  concerned  through 
on-line  measures. 

In  sum,  SIGMA  has  a key  precursive  role  in  force  selection  and 
preparation  and  is  a pre-process  integral  to  both  LOGSACS  and  PERSACS 
computation.  When  SIGMA's  role  in  force  preparation  is  completed,  the 
Force  Accounting  and  Systems  Division  (DAMO-FDA) , ODCSOPS,  signals 
USAMSSA  that  the  force  is  ready  for  a SACS  computation.  USAMSSA  then 
proceeds  to  Basic  SACS  processing  (requisite  to  both  LOGSACS  and  PERSACS) 
culminating  in  a "FIRST  STOP"  processing  pause  for  accuracy  analysis 
prior  to  continuation  of  LOGSACS  or  PERSACS  processing. 

For  descriptive  purposes,  SIGMA  is  functionally  divisible  into 
six  discrete  functions: 

• Load  the  SACS  force. 

• Overlay  TAADS/TOE  files  and  match  to  the  SACS  force. 

• Edit  overlay,  identify  mismatch/strength  aberrations,  produce 
errors  report. 

• Update  records  and  correct  errors  via  CRT. 

• Assess/validate  target  totals  summarizing  SIGMA  process 
outcomes . 

• Release  the  SACS  force  to  USAMSSA  for  SACS  computation. 

Each  of  these  SIGMA  functions  Is  accomplished  via  CRT  (hard- 
wired into  USAMSSA)  by  DAMO-FDA  personnel.  Each  is  described  in  the 
following  paragraphs. 

(1)  Load  the  SACS  Force.  Before  SIGMA  users  can  effect  a SACS 
force  load,  four  conditions  must  obtain: 


available. 


• The  Q Force  tape  file  copied  from  the  FAS  file  must  be 


• The  desired  TAADS  file  (a  tape  file)  must  be  available. 
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• The  desired  TOE  file  (a  tape  file)  must  be  available. 

• User  authority  for  legitimate  SIGMA  program  access  must 
be  recognized  by  the  system. 

Prior  to  initiation  of  a SACS  force  load,  USAMSSA  must  be 
notified  of  the  SIGMA  user's  intent  to  load  a SACS  force  so  that  the  Q 
Force  (selected  unit  file),  TAADS  and  TOE  tape  files  may  be  made  avail- 
able for  load  to  SIGMA's  LOG  or  PER  disk  area. 

After  successful  entry  into  the  SIGMA  process,  the  user  is 
provided  several  options  in  CRT  display  form: 


OPTION  LIST 

PLEASE  ENTER  ONE  OF  THE  FOLLOWING  OPTIONS: 


T-TO  TERMINATE  JOB 
LOAD- LOADS  SELECTED  FAS  FORCE 
OVERLAY -OVERLAY  FAS  FILE  WITH  TAADS 
EDIT-FOR  EDIT  OPTION  LIST 
VIEW-DISPLAY  SPOOLED  DATA  FROM  EDIT 
S-TO  PAGE  TO  NEXT  SEQUENTIAL  SUBSET 


NOTES-TO  SPOOL  NOTE  FILE, 

AFTER  NOTES  ARE  SPOOLED 

ENTER  P-TO  PAGE  SEQUENTIALLY 

THROUGH  UICS  WITH  NOTES 

R-TO  RELEASE  COMMAND  REPORTS 

F-TO  RELEASE  FORCE  TO  SACS 
(DO  NOT  USE  THIS  CODE)* 


ENTER  EIGHT  POSITION  KEY  TO  VIEW  A SPECIFIC  UIC  (FORCE,  COMPO,  UIC) 


Figure  1.1.  Display:  Option  List 

At  this  point  in  SIGMA  processing  the  user  must  signal  intent 
to  LOAD  the  SACS  force  in  response  to  the  OPTION  LIST  prompt  by  typing 
the  word  "LOAD"  into  the  CRT  display  terminal.  Control  is  now  passed  to 
the  SIGMA  LOAD  module. 

The  SIGMA  LOAD  module  presents  a prompting  display  to  the 
user  in  order  to  ascertain  specifics  of  force  selection  criteria.  The 
user  is  asked  to  first  enter  the  security  key,  enter  the  command  "LOADIT" 
and  then  provide  the  following: 


I-b 


• Force  Code  (FORCO)  - (e.g. , II  is  used  to  designate  the 
"frozen"  Master  Force  or  Q Force). 

• Component  Code  (COMPO)  - (Normally  1,  2,  3 or  4 where 

1 " Active  Army;  2 ■ National  Guard;  3 ” Army  Reserve;  and  4 « Unmanned 
Army) . 

• New  FORCO  (for  example,  "S"  or  any  other  alpha  designator 
assigned  by  the  user) . 

• Termination  Date  (TDATE)  of  SACS  computational  time  frame. 

• Effective  Date  (EDATE)  of  start  of  SACS  computational  time 


frame. 


LOGSACS) 


Type  of  SACS  being  loaded  (PERS  for  PERSACS  or  LOG  for 


For  purposes  of  our  discussion  example  addressed  in  the  following 
paragraphs,  the  force  selection  criteria  are: 


FORCE 


COMPO 


New  FORCO 


TDATE 

800930 


EDATE 

780101 


The  display  format  for  the  force  selection  criteria  prompt  appears 


to  the  user  as: 


USAMSSA 


CSB-LOADER 


USAMSSA 


THIS  LOAD  PROGRAM  WAS  DEVELOPED  TO  COPY  A FORCE  FROM  FAS  USING  SACS 
SELECTION  CRITERIA. 

ENTER  THE  SECURITY  KEY 

THE  FORCE  CODE,  THE  COMPO,  THE  NEW  FORCE  CODE,  1-3 
THE  TDATE  AND  THE  EDATE  4-15 

THE  TYPE  OF  SACS  BEING  LOADED  - PERS,  EQUIP. 

A LISTING  OF  RECORD  KEYS  WILL  BE  PRODUCED 


Security  - KEY  123456789012345678901234567890 
LOAD IT  M1S800930780101PERS 


Figure  1.2.  Display:  CSB-LOADER 
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In  the  current  example,  after  the  user  types  in  the  specifics  of 
the  force  selection  criteria  and  depresses  the  ENTER  key,  the  force  load 
is  initiated  such  that  the  Q Force  (COMPO  1)  for  the  time  frame  ranging 
from  780101  to  800930  is  loaded  Into  the  PERS  disk  area  and  the  loaded 
force  is  assigned  a new  name,  S.  A convenient  convention  is  to  assign 
P to  a selected  force  destined  to  be  used  in  a PERSACS  computation  and 
L to  a selected  force  to  be  employed  within  a LOGSACS  computation. 

Only  one  COMPO  may  be  loaded  at  any  one  time.  Thus,  if  the  SIGMA 
user  has  a requirement  to  load  COMPOs  1,  2,  and  3,  for  example,  then 
three  discrete  loads  (with  attendant  "LOADIT"  force  specifications  as  per 
Figure  1.2.)  must  be  accomplished.  Time  to  load  a given  COMPO  is  gener- 
ally contingent  upon  the  number  of  records  contained  within  the  COMPO  and 
may  require  up  to  several  minutes.  While  the  force  is  loading,  the  user 
is  kept  informed  (at  one  minute  intervals)  of  the  number  of  records  load- 
ed. A final  record  count  display  for  the  force  specified  in  the  previous 
example  might  be  as  follows: 


M1S800930780101PERS 

Cl 

v5  1 

SACS 

FILE 

LOAD  COUNTS 

A - INPUT  PROFA 

7,596 

B - FAILED  PRE-TDATE 

I - TOTAL  MTOE  UNITS 

4, 

EDATES  GREATER  800930 

350 

BLANK  CCNUM 

C - FAILED  POST  - TDATE 

FORCED  CCNUM 

TDATES  LESS  780101 

4 

J - TOTAL  TDA  UNITS 

2, 

D - FORCO,  SPLITS 

2 

BLANK  CCNUM 

E - DUPLICATE  RECS  DROPPED 

0 

K - TOTAL  NOTES 

F - ACTC0  - J RECS  DROPPED 

201 

RELATIONSHIP  OF  FILE 

COUNTS 

G - SELECTED  UNITS 

7,039 

A-B-C-D-F  - G C.  - I 

+ J 

H - DISPLAY  ONLY  UNITS  (DO) 

212 

ENTER  C FOR  ANOTHER  COMPO  LOAD 

LOAD  RAN  IN  o MIN  54  SEC  00 

OR  T TO  TERMINATE 

Figure  1.3.  Display:  SACS  File  Load  Counts 
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Thus,  COMPO  1 units  selected  total  7,039  in  the  current  example 
from  the  Q Force  of  7,596  units.  This  unit  selection  is  composed  of 
MTOE  and  TDA  units  within  C0MP0  1 as  constrained  by  the  specified  EDATE 
and  TDATE.  having  loaded  COMPO  1,  the  user  may  proceed  to  load  additional 
COMPOs  or  to  terminate  the  LOAD  module.  Additional  COMPOs  are  loaded  in 
accordance  with  the  procedures  we  have  already  described.  If  the  user 
indicates  LOAD  termination,  SIGMA  returns  to  the  OPTION  LIST  display 
(Figure  1.1.)  from  which  the  user  should  select  the  next  SIGMA  action 
option:  OVERLAY . 

(2)  Overlay  TAADS/TOE  and  Match  to  the  SACS  Force.  Having 
selected  the  OVERLAY  option,  the  SIGMA  user  must  initiate  two  required 
overlay  passes  one  at  a time.  Displays  for  overlay  specification  and 
record  count  are  similar  for  both.  For  example,  on  the  first  overlay 
pass  the  user  will  be  asked  to  provide  specification  data  as  shown 
below: 


USAMSSA  COMPUTATIONAL  SYSTEMS  BRANCH 

TAADS  OVERLAY  OF  FAS  WITH  OPTIONS  - USE  OVERLAY  HANDOUT  #1 
ENTER  'T'  TO  TERMINATE 

ENTER  YOUR  9 POSITION  SECURITY  KEY  (OVERLAY#*/)  FOLLOWED  BY  CONTROL 
STATEMENT 

TYPE  1-7,  EDATE  8-13,  FORCE  14,  COMPO  15-19,  TYPCO  20-22,  DELETE  23, 
CARDS  24,  TAPE-OR-CARDS  25,  SRCTO  26,  LOGIC  27-28,  TYPE-TAADS  29 

SECUR-KEY0000000001111111111222222222233333333334 

1234567891234567890123456789012345673901234567890 


Figure  1.4.  Display:  Computational  Systems  Branch 


'T' 


As  was  the  case  in  the  force  load  procedure,  record  counts  are 
displayed  for  user  information  at  one  minute  intervals  until  the  overlay 
is  completed: 


OVERLAY  COMPLETED 


FAS  READ  - 

5632 

LOGIC  HITS  FOR  SACS  - 

2 

TAADS  READ  - 

13530 

UNMATCHED  FAS  RECORDS  - 

119 

TRANS  OUT  - 

4 

SRCTO  OR  ASGMT  CHECKS  - 

53 

BLANK  CCNUMS  - 

55 

OVERLAY  RAN  IN 

: 1 MINS  12  SECS 

ENTER:  T - TO  TERMINATE  OR  C - FOR  ANOTHER  OVERLAY 


Figure  1.5.  Display:  Overlay  Completed 

Two  overlays  are  required  during  SIGMA.  The  first  overlay  is 
performed  separately  by  COMPO  for  approved  TAADS  documents  only.  It 
overlays  TAADS  CCNUM  and  MTOEC  data  elements  into  the  Selected  Units 
record  if  they  are  blank.  The  second  overlay  is  performed  for  all  other 
matched  TAADS  documents,  and  overlays  the  CCNUM  and  MTOEC  data  elements 
into  the  applicable  records  of  the  Selected  Unit  file  if  they  are  blank. 

After  both  overlays  are  completed,  SIGMA  returns  to  the  OPTION 
LIST  display  and  the  EDIT  option  is  normally  selected. 

(3)  Edit  Overlay,  Identify  Mismatch/Strength  Aberrations,  Produce 
Errors  Report.  The  EDIT  Module  has  the  capability  of  performing  two  types 
of  edits: 

• Identification  of  unmatched  units. 

• Identification  of  units  with  critical  strength  differences 
relative  to  their  corresponding  resource  documents. 

Within  the  EDIT  Module,  the  user  is  first  asked  to  provide 
specific  force-identifying  information  as  indicated  by  the  following 
CRT  display: 
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YOU  HAVE  CHOSEN  THE  EDIT  OPTION 

PLEASE  ENTER  FORCE,  COMPO,  AND  SIX  * TO  START  EDIT  AT  BEGINNING  OF  COMPO 
OR  FORCE,  COMPO,  AND  UIC  TO  START  AT  A PREDETERMINED  POINT  IN  FILE 


I I 


T - TERMINATE  EDIT 
V - VIEW  SPOOLED  DATA 


Figure  1.6.  Display:  Edit  Option 

The  user  identifies  the  force  to  be  edited  and  has  the  option 
of  beginning  the  edit  from  the  first  record  in  the  force  file,  or  from 
any  predetermined  point  in  the  force  file  bv  specifying  UIC.  When  the 
force  to  be  subjected  to  the  edit  has  been  identified,  the  user  is 
shown  the  following  display  from  which  to  choose  the  type  of  edit  to  be 
performed : 


EDIT  OPTION  LIST 

PLEASE  ENTER  ONE  OF  THE  FOLLOWING  OPTIONS 
T - TERMINATE  EDIT 

EDIT  - SIMULATES  FIRST  STOP  LOGIC  - SPOOLS  ERRORS 

EDIT3XXX  - CHECKS  PERCENTAGE  OF  FACTORING,  REPLACE  XXX  WITH  DESIRED 

PERCENT 

VIEW  - DISPLAY  SPOOLED  DATA  FROM  EDIT 

.ADD  FOR  TARGET  PROCRAM:  CHOOSE  EDIT  OPTION. 

FORCE/COMPO/ ****** . 

EDIT  OPTION  PAGE.  TYPE  TARGET  (COMPO  IS  EDITED). 
TERMINATE:  CHOOSE  TARGET:  ENTER  DATES  (UP  TO  3) 


Figure  1.7.  Edit  Option  List 
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Normally,  the  first  option  selected  is  "EDIT."  nils  edit  matches 
the  FAS  file  against  TAADS  or  TOE  and  displays  unmatched  units.  All 
COMPOs  are  edited  in  one  pass.  When  errors  are  spooled,  they  are  auto- 
matically written  to  a designated  disk  area  from  which  they  may  later 

be  requested  for  viewing.  A hardcopy  report  of  all  errors  deriving  from 

it 

mismatching  conditions  is  produced  by  USAMSSA  for  the  SIGMA  user's 
Investigation  of  mismatch  causative  factors.  The  data  contained  in 
this  report  listing  is  formatted  (by  COMPO)  as  follows: 

FOSCK  - l ccmpo  - l 

'JTC  ETATt  TrATE  CCNUM  SRC  MTOEC  TAP  FACS  TACR  (MESSAGE) 

.'ABDA  TeObll  ?9<me>  Fears  06301H300100  06301HFCS3  LCD  351  303  BAD  CCNUM 


W.iarn: 

:.V?  Typa  Coda  (1,  3 or  33 

Activation  Goda  (C,  J.  H,  G) 

Phaaa  Coda  (D.  A,  C,  M3 
FACT  la  :!>a  Forca  Aggregate 
TAGR  l*  tba  TAADS  aggregate 

MESSAGE  will  ba  arror  descriptive  (a.g.,  BAD  MTOEC,  SO  MATCH3 
Other  element*  are  it  generally  defined  elsewhere 


i 


Figure  1.8.  Hardcopy  EDIT  Errors  Report  Format 

Each  discrepant  unit  is  listed  as  a result  of  the  initial  edit 
procedures.  The  edit  error  listing  of  discrete  problematic  units  is 
summarized  at  the  end  of  the  report  as  follows: 


■- 

i 

Lj 
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NOTE:  ».\OFA  RECORDS  READ"  refers  specifically  to  the  copy  of  the  FAS 

file  containing  unit  records  exclusive  of  MANX  and  Notes  File  data;  see 
FAS  Appendix  F for  a discussion  of  the  latter  two  files. 


Resolution  of  mismatching  conditions  as  reflected  by  the  error 
report  listing  (referred  to  as  "scrubbing"  the  odit  listing)  may  be 
accomplished  by  user  manual  research  effort  utilizing,  in  combination, 
the  following  primary  reference  materials  generated  by  USAMSSA: 
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Figure  1.9.  Hardcopy  EDIT  Error  Summary 


Report  Title 
TAADS  Header  Report 
Comp  File  Digest  Substitute 
Monthly  SRC  Changes 

AMS  PAAL 


Number  of  Volumes 
3-4 
1 
1 

3 


FORCE  - L 

SICMA  FIRST  STOP  EDIT 

COMPLETE 

1 

COMPO  - 1 

FORFA  RECORDS  READ 

- 8,317 

TAADS  RECORDS  READ 

- 24,399 

NUMBER  SRCS  READ 

- 1,036 

MATCHED  TAADS 

- 7,226 

MATCHED  SRCS 

- 1,036 

RECORDS  SPOOLED 

171 

FACTORED  BY  0% 

0 

UNMATCHED  RECORDS 

55 

I 

l 


While  the  edit  is  processing,  record  counts  are  displayed  on  the  user's 
CRT  at  one  minute  intervals  in  a format  similar  to  the  edit  hard  copy 
summary.  The  record  count  shows  both  the  number  of  records  read  and  the 
number  of  mismatched  units  (to  a maximum  of  999) : 


SIGMA  FIRST  STOP 

EDIT 

COMPLETE 

************ 

* * 

* * * * * 

* 

* FORFA  RECORDS  READ 

- 

5,659 

* 

* TAADS  RECORDS  READ 

- 

13,530 

* 

* NUMBER  SRCS  READ 

- 

182 

* 

* MATCHED  TAADS 

- 

5,445 

* 

* MATCHED  SRCS 

- 

182 

* 

* RECORDS  SPOOLED 

- 

194 

* 

* FACTORED  BY  0% 

- 

0 

* 

* UNMATCHED  RECORDS 

- 

32 

* 

************ 

* * 

* * * * * 

* 

TIME  2 MIN  26  SEC  ENTER:  C-TO  CONTINUE 

V - VIEW 

SPOOL  T - TERMINATE 

Figure  I. 10.  Display:  Sigma  First  Stop  Edit  Complete 

(4)  Update  Records  and  Correct  Errors  via  CRT.  Correction  updates 
to  the  selected  force,  based  upon  SIGMA  user  mismatch  resolutions,  are 
performed  in  batch  mode  by  USAMSSA. 

All  corrective/updating  actions  employed  by  the  SIGMA  user  must 
be  executed  in  batch  mode.  All  batch  updates  (whether  directed  toward 
P or  L Force)  are  applied  to  the  Q Force.  Thus  the  "frozen"  or  ongoing 
M Force  files  are  unaffected  by  SIGMA  updates.  The  corrections  made  to 
SACS  data  via  SIGMA  are  output  on  listings  to  Command  and  Force  Managers. 
It  is  then  incumbent  upon  them  to  code  and  input  these  corrections  to  a 
subsequent  update  of  the  FAS  file  in  order  that  corrections  made  via 
SIGMA  may  become  a matter  of  permanent  record,  if  approved. 


■ 

t“ 

l.| 

* 


! 


'] 


j 
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Batch  updates  are  generally  accomplished  after  regular  working 
hours.  When  the  Q Force  update  is  completed  (by  the  next  morning)  the 
selected  P or  L Force  may  be  reloaded  from  Q into  the  appropriate  SIGMA 
PER  or  LOG  work  area  on  disk.  The  impact  of  the  force  update  is  assessed 
as  the  user  executes  OVERLAY  and  EDIT  options,  as  previously  discussed. 
The  batch  update  reload  cyclical  procedure  is  reiterated  until  the  user 
is  satisfied  that  the  selected  force  and  resource  documents  are  "clean" 
and  have  high  quality  interface  potential  for  computations  within  a 
SACS  environment. 

An  important  additional  force  and  interface  assessment  option. 
Percentage  Factoring,  is  available  to  the  user  with  the  SIGMA  EDIT 
module.  It  identifies  units  having  TAADS/TOE  resource  document  strengths 
departing  by  more  than  a specified  percentage  from  the  strength  aggrega- 
tions copied  from  FAS.  The  user  may  select  a percentage  factor  ranging 
from  0%  to  100%.  Results  are  of  particular  consequence  to  PERSACS  users 
in  early  identification,  assessment,  and  correction  where  possible  of 
broadly  disparate  P Force  vs  resource  document  unit  strengths.  Absent 
correction,  operation  of  the  PERSACS  FACTORING  function  (see  PERSACS 
Appendix  G)  can  induce  substantive  grade,  military  occupational  specialty 
(MOS),  and  strength  distortions  in  PERSACS  output. 

The  Percentage  Factoring  Edit  is  the  "EDIT3XXX"  system  in  the 
EDIT  option  list  (Figure  1.6.)  where  XXX  may  assume  a percentage  value 
ranging  from  0 to  100.  The  percentage  specified  serves  as  the  compare 
criteria  in  the  Percentage  Factoring  Edit  wherever  all  documented 
strengths  requiring  XXX%  or  more  factoring  (in  order  to  come  into  agree- 
ment with  authorized  strength  in  the  selected  forces  file)  are  assembled 
and  listed  out  in  a report  for  user  evaluation.  As  outlined  above,  the 
Percentage  Factoring  Edit  thus  facilitates  the  user's  identification  of 
records  which  would  require  extraordinarily  high  percentages  of  factor- 
ing if  allowed  entry  into  the  SACS  environment  without  modification.  In 
this  way,  gross  strength  errors  may  be  caught  and  corrected. 

SIGMA  has  sufficient  disk  space  allocated  for  spooled  errors  to 
accommodate  up  to  300  errors.  To  qualify  for  error  spooling,  a mismatch- 
ing condition  may  exist  or  a record  may  require  more  than  XXX%  factoring. 
That  is,  SIGMA  presently  makes  no  distinction  between  errors  spooled  for 
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reasons  of  mismatch  or  of  excessive  factoring  ret)ui cement  s . Out  of  con- 
sideration for  this  limited  disk  space,  the  SIGMA  user  will  normally 
correct  ("scrub")  unit  mismatch  conditions  before  initiating  tlte  Percent- 
age Factoring  Edit. 

(5)  Assesa/Val Ida  to  Target  Totals  Summarising  SIGMA  Process 
Outcomes . A final  option  available  to  the  St  (IMA  user  is  the  Target  Pro- 
gram. Target  totals  are  the  l’FRSACS-or tented  "last  step/final  check" 
in  SIGMA  processing.  The  identification  of  remaining  unmatched  units 
coupled  with  the  display  of  records  read,  matched,  spooled  and  unmatched, 
and  other  MACOM-speeif ic  data,  are  used  by  the  PFRSACS  analyst  as  broad 
Indices  of  strength  validity  preparatory  to  basic  SAGS  processing.  The 
Target  Program  option  results  lit  a hardcopy  printout  containing  three 
general  classes  of  display  data: 

• Identification  of  nonmatching  units  bv  IMF. 

• Summarization  totals  of  records  read,  matched,  unmatched  and 

spoo  led . 

• Personnel  category  (OFF  **  commissioned  officer,  WOF  - warrant 
officer,  FNl.  - enlisted,  AGR  - military  aggregate,  CIV  - civilian) 
strengths  across  "validity"  Indices  by  MACOM. 

The  three  display  classes  are  ordered  first  bv  date.  At  the  out- 
set the  Target  totals  user  provides  three  dates.  Typically,  these  dates 
are  chosen  so  as  to  be  evenly  distributed  across  PKRSACS-addressed  rears. 
For  example,  from  an  October  1878  PF.RSACS  the  user  might  specify  dates 
of : 


'SI  001 


820810 


SS0‘>  10 


I FY  78  Execution  year 
FY  80  budget  year 
I FY  SI  Program  vear 
1 FY  82 
FY  8 3 v 

Out  years 

FY  84  j 
FY  85* 
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Within  the  time  frames  bounded  by  the  three  dates  specified,  the 
display  classes  are  ordered  by  COMPO  and,  within  COMPO,  the  display 
classes  are  presented  in  the  order  given  above.  The  first  display  class 
is  a listing  of  unmatched  units,  by  UIC,  in  the  format  given  below  as  an 
examp ie : 


FORCE  = 

P 

COMPO  » 1 

UIC 

EDATE 

TDATE 

CCNUM 

SRC  MTOEC  TAP 

FAGR  TAGR 

WAQY90 

790930 

790315 

11111T 

2AA 

8 NO  MATCH 

Figure  I. 11.  Display:  Target  Listing  of  Unmatched  Units 

Those  unmatched  units  not  amenable  to  resolution  bv  user  analvst 
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effort  may  be  referred  to  the  appropriate  Force  Manager  for  resolution 
by  liaison  with  appropriate  MACOMS.  Unmatched  units  cannot  be  included 
in  SACS  computations. 

The  second  display  class  is  a summary  of  records  read,  matched, 
spooled  and  unmatched.  Again,  this  display  occurs  by  Date  and  by  COMPO 
and  follows  the  general  format  shown  in  Figure  1.12.  It  precedes  and 
is  used  by  the  PF.RSACS-oriented  analyst  in  conjunction  with  the  third 
display  class  shown  in  Figure  1.12. 
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FORCE  - P 


COMPO  - 1 


SIGMA  FIRST  STOP  EDIT  COMPLETE 

******************* 


* FORFA  RECORDS  READ  - * 

* TAADS  RECORDS  READ  - * 

* NUMBER  SRCS  READ  - * 

* MATCHED  TAADS  - * 

* MATCHED  SRCS  - * 

* RECORDS  SPOOLED  - * 

* FACTORED  BY  02  * 

* UNMATCHED  RECORDS  - * 


******************* 

TIME  MM  MIN  SS  SEC  ENTER:  C - TO  CONTINUE  V - VIEW  SPOOL 
T - TERMINATE 


NOTE:  "FORFA  RECORDS  READ"  refers  specifically  to  the  copy  of  the  FAS 
file  containing  unit  records  exclusive  of  MANX  and  Notes  File  data;  see 
FAS  Appendix  F for  a discussion  of  the  latter  two  files. 

Figure  1.12.  Display:  TARGET  Summary  of  Records 

The  third  display  class,  also  ordered  by  Date  and  COMPO,  is  an 
expansion  by  MACOM  of  the  preceding  displays.  This  display  takes  the 
general  form  shown  in  Figure  1.13.  and  is  "rolled  up"  by  COMPO  to  a 
summarized  level,  in  Date  totals,  in  the  general  form  shown  in  Figure 
1.14.  For  both  Figure  1.13.  and  Figure  1.14.,  the  following  definitions 
apply : 

• "FAS"  - Strength  totals  in  each  personnel  category  as  con- 
tained in  the  P Force  derived  from  the  Q Force  copy  of  the  FAS  selected 
units  file. 

• "UNDOC  TDA"  - Strength  totals  in  each  personnel  category 

for  TDA  units  in  the  selected  force  which  are  unmatched  by  TAADS  resource 
documents . 
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• "UNMTCH  TOE"  - Strength  totals  in  each  personnel  category 
for  MTOE  units  in  the  selected  force  which  are  unmatched  by  either  TAADS 
or  TOE  resource  documents. 

• "PERSACS"  - Strength  totals  in  each  personnel  category  for  the 
PERSACS  P Force. 

• "AVAIL  TAADS"  - Strength  totals  in  each  personnel  category 
for  units  in  the  selected  force  which  have  been  matched  to  TAADS  resource 
documents. 

• "AVAIL  TOE"  - Strength  totals  in  each  personnel  category  for 
MTOE  units  in  the  selected  force  which  have  been  matched  to  TOE  resource 
documents. 

• "FAC  TAD"  - Indicates  incidence  by  personnel  category  of 
Factoring  which  will  be  necessary  in  SACS  processing  to  bring  TAADS 
documented  manpower  strengths  up  to  or  down  to  P Force  strengths  derived 
from  FAS. 

• "FAC  TOE"  - Indicates  incidence  by  personnel  category  of 
Factoring  which  will  be  necessary  in  SACS  processing  to  bring  TOE  docu- 
mented manpower  strengths  up  to  or  down  to  P Force  strengths  derived 
from  FAS. 


DATE:  YYMMDD 
DATE  TOTALS: 
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OFF  WOF  ENL  AGR  CIV 

FAS 

UNDOC  TDA 
UNMTCH  TOE 
PERSACS 
AVAIL  TAADS 
AVAIL  TOE 
FAC  TAD 
TAC  TOE 


Figure  1.14.  Display:  TARGET  Totals  by  Date 

These  displays  facilitate  analyst  assessment  of  the  plausibility 
of  unit  personnel  composition  and  structure  across  personnel  category,  bv 
MACOM  and  by  COMPO.  Certain  expected  internal  consistencies  support 
such  analyses.  These  expectations  include  relationships  such  as  the 
following: 

FAS  = (UNDOC  TDA  + UNMATCH  TOE  + PERSACS) 

PERSACS  > (FAC  TAD  + FAC  TOE) 

(AVAIL  TAADS  + AVAIL  TOE)  > (FAC  TAD  + FAC  TOE) 

Of  paramount  importance  to  the  "final  checking"  of  the  force, 
before  it  is  released  from  SIGMA  for  use  in  Basic  SACS,  is  analysts' 
comparison  of  TARGET  personnel  category  totals  with  a "Summary  of  DA 
Manpower  Program  by  Command/FY"  provided  by  DAMO-FDP  and  presented  in  a 
format  showing  military  and  civilian  manpower  by  MACOM  as  shown  in  Table 
1.1.  The  summary  manpower  data  presented  represent  program  budget  guid- 
ance manpower  ceilings  by  personnel  category  across  all  MACOMs  and  may 
not  be  exceeded. 

(6)  Release  the  SACS  Force  to  USAMSSA  for  SACS  Computation.  When 
the  review  of  TARGET  totals  is  accepted  as  demonstrating  SIGMA  preparatory 
processing  to  have  satisfactorily  purified  the  selected  force,  the  force 
is  released  to  USAMSSA  for  SACS  processing. 
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6.  CONTRIBUTION  TO  SACS 

SIGMA's  contributions  to  SACS  derive  from  its  characteristic  partial 
emulation  of  the  Basic  SACS  process  on  a substantively  more  expeditious 
basis.  The  system  objective  is  to  assure  rapid  pre-identification  of 
real  or  potential  unit  versis  personnel  document  mismatch  and  strength 
discrepancies  which  otherwise  would  not  become  manifest  until  Basic  SACS 
execution,  with  ensuing  significant  problem  resolution  and  Basic  SACS 
re-run  delays.  In  addition  to  its  "mini-Basic  SACS"  emulative  capability, 
SIGMA  features  a corrective/updating  function,  not  available  in  SACS 
endogenous  processing,  which  can  be  directed  toward  the  "purification" 
of  real  or  potential  problems  before  the  applicable  files  are  united  in 
a "live"  SACS.  To  the  extent  that  SIGMA  is  successful  in  its  role  of 
selecting  a SACS  Force  and  assuring  near  error-free  interface  with  TAADS 
and  TOE  files  employed  in  SACS,  its  contribution  to  SACS  data  quality  and 
outcomes  is  significant. 

7.  MAJOR  DATA  ELEMENTS 

ACTCO  Action  Code,  indicates  the  force  structure  change  applicable 
to  a unit  on  a given  date,  i.e.,  activation,  inactivation, 
reorganization,  gain  to  a command. 

ADCON  Administrative  Control  Code,  the  UICCC  of  the  headquarters  or 
higher  unit  which  exercises  administrative  control  over  the 
unit . 

AI.OST  Authorized  Level  of  Structure,  level  1,  2,  3,  B,  or  C for 

officer,  warrant  officer,  and  enlisted  personnel.  Applicable 
to  TOE  records  only. 

AMS CO  Army  Management  Structure  Code,  the  major  fiscal  language  code 

used  for  Army  PPBS  and  for  the  Army  budget  presentation  before 
Congress . 

ASGMT  Assignment . the  major  command  or  PA  Staff  Agency  to  which  the 
unit  is  assigned.  For  NG  and  AR  units,  the  ASGMT  is  used  to 
designate  Army  Reserve  Commands  (ARCOMS)  and  Army  Reserve 
Gene ra 1 Officer  Commands  (GOCOMS 1 . 

Al'STR  Authorized  Strength,  officers,  warrant  officers,  enlisted  per- 


sonnel. military  aggregate,  and  civilian  US  direct  hire,  foreign 
direct  hire,  indirect  hire,  and  civilian  aggregate. 
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COMNT 

COMPO 

DAMPL 

DEPLO 

DPMNT 

DSCMP 

EDATE 

ELS  EQ 

ESCON 

FICOD 


Authority . directive,  or  concept,  authorizing  the  transaction. 
Included  in  the  history  file  for  audit  trail  purposes. 

Branch,  the  branch  of  service  under  which  a TOE  unit  is  organized. 
Combat  Arms  Regimental  System,  the  historical  designation 
assigned  to  combat  and  combat  support  units  of  Infantry,  Armor, 
Field  Artillery,  and  Air  Defense  Artillery  TOE  units. 

Command  Control  Number,  the  major  FAS/TAADS/VTAADS  linking 
code.  Identifies  the  command  assignment,  changes  and  fiscal 
year  for  all  TAADS  documents. 

Civlian  Control  Number,  summary  level  aggregate  of  units  which 
are  applied  against  the  military  strength  portion  of  a command's 
manpower  ceiling. 

Component  Code,  applies  to  the  PROFA  notes  file.  See  COMPO  for 
definition. 

Component  Code,  indicates  Active  Army,  Reserves,  National  Guard 
or  others. 

DA  Master  Priority  List,  priority  grouping  of  all  units  or 
activities  for  the  allocation  of  personnel  and/or  equipment. 
Deployment  Package  Assignment,  special  unit  mobilization 
category. 

Deployment  Designation,  indicates  the  deployment  area  and  month 
for  units  scheduled  for  movement  in  the  event  of  general  war 
mobilization. 

Display/Compute  Indicator,  for  report  display  purposes;  a FAS 
and  SACS  indicator  if  computation  has  taken  place. 

Effective  Date,  the  date  on  which  the  unit's  force  structure 
position  becomes  effective. 

Element  Sequence  Number,  sequences  the  subordinate  units  of 
major  units,  e.g.,  battalions  which  are  part  of  a division. 
Equipment  Serviceability  Condition  Code,  actual  current  equip- 
ment readiness  for  deployment. 

Force  Identification  Code,  identifies  the  particular  FAS  Force 
in  the  multiforce  file. 
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FINOT  Forces  Ident if lcat ion  Code,  identifies  forces  in  the  notes  file. 

FNCAT  Functional  Category,  a manipulative  FAS  code  used  for  miscel- 
laneous force  structure  aggregations. 

FORCO  Force  Code,  a computational  code  identifying  special  authoriza- 
tions or  exception  units. 

FPLAN  Force  Planning  Code,  the  major  FAS  management  language  used  to 
structure  Army  units  and  force  packages. 

JCSTY  JCS  Unit  Type  Code,  describes  the  type  of  unit  for  which  the 
force  requirement  is  stated. 

MACTO  Month  and  Action  Code,  contemplated  deployment  action  for  units 
not  mobilized  until  after  M-day. 

MBCMD  Mobilization  Command  Assignment,  major  command  or  agency  to 
which  units  are  assigned  after  mobilization. 

MRLOC  Mobilization  Location  Code,  location  of  a unit  on  or  after  M- 
day;  Indicates  the  Army  area  and  state  for  units  in  contental 
locations  and  overseas  abbreviation  for  units  in  theater. 

MBPRP  Mobilization  Period,  indicates  appropriate  month  after  M-day 

that  a unit  will  be  activated  or  called  to  active  military 
service. 

HBSTA  Mobilization  Station,  the  current  station  for  CONUS  active 

Army  units;  the  overseas  location  for  Army  Reserves,  National 
Guard,  and  other  component  units. 

MGCMD  Major  Command. 

MILCN  Military  Control  Number,  summary  level  aggregate  of  units 

which  are  applied  against  the  military  strength  portion  of  a 
command's  manpower  ceiling. 

MTOEC  Modified  Table  of  Organization  and  Equipment  Control  Number,  a 
major  FAS/VTAADS  linking  code  for  TOE  units.  Identifies  the 
first  six  positions  of  the  unit's  SRCTO,  its  command  assignment, 
and  the  latest  document  change  number.  An  MTOEC  equal  to 
qqququQuuq  indicates  that  the  document  is  not  a VTAADS  document. 

NED AT  Effective  Date  for  the  Notes  File,  equals  the  FAS  EDATE  for  the 

matching  SRCTO. 

N'TREF  Note  Reference  Number,  a reference  which  includes  additional 


descriptive  information  for  a unit. 
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NTSRC  Note  Change , note  reference  change  number.  Same  as  CHGNR  in 
PROFA. 

NUMBR  The  number  of  times  a single  notes  file  standard  requirements 
code  Is  computed  within  Its  UICCC. 

OPAGP  Operating  Agency  Code.  DA  organizational  element  to  which  funds 
are  allocated  or  suballocated. 

OPDAT  Operating  Pate,  indicates  the  date  of  unit  assignment  to  the 
force  commitment  of  the  NATO  Defense  Planning  questionnaire. 

OPSTR  Operating  Strength,  by  officer,  warrant  officer,  enlisted, 
aggregate  military,  and  civilian. 

PECOD  Program  Element  Code,  the  major  DOD  management  language  vised 
to  aggregate  units,  manpower,  and  dollars  associated  with  the 
FYDP  structure. 

PHASE  Phase  Code,  the  authority  for  a unit  record.  Phase  D or  C, 
indicates  th3t  the  record  is  supported  by  an  approved  TAADS 
document  or  general  order.  Any  other  PHASE  Code  indicates 
that  the  unit  has  an  approved  program  position  not  yet  supported 
by  TAADS  or  a general  order.  M ■ DA  message  or  letter;  C - 
Command  originated  change;  A » Approved  Program  Assumption; 

S * DA  Staff  Actions. 

PRCON  Personnel  Readiness  Condition  Code,  actual  current  level  of 
personnel  readiness  of  a unit. 

REPCO  Report  Code,  a code  used  to  retrieve  mobilization  reports  from 
the  file. 

ROBCO  Readiness  Objective  Code,  for  active  Army  units,  designates 
units  according  to  light/heavy’  corps  concept.  For  AR  and  NG 
units,  designates  units  according  to  readiness  concepts. 

SPLIT  Split  Unit  Indicator,  identifies  those  parent  UICCs  and  their 
subelements  which  are  located  at  different  command  assignments. 
Additionally,  the  parent  unit  and  the  subelement  must  have 
unique  TAADS  documents. 

SRCTO  Standard  Requirements  Code,  identifies  the  basic  TOE  plus  any 
variances  for  personnel  and  equipment  in  a TOE  unit. 
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STNNM 


STSTR 


TDATE 

TXCCC 

TPSNA 

TRCON 

TODAY  or 
TDATE 

TYPCO 

UICCC 

UNCAP 

UNCLC 


UNCON 


Status  Code,  classifies  the  status  of  active  Army  STRAF  units 
by  state  of  readiness  for  use  in  specific  missions  or  activites. 
Other  units  mav  be  classified  as  CONUS  operating,  theater,  reim- 
bursable, ARADCOM,  special  foreign  activities,  exception  units, 
or  deployable. 

Station  Name,  a meaningful  abbreviation  of  the  unit's  geo- 
graphical location. 

Structure  Strength,  officers,  warrant  officer,  enlisted  per- 
sonnel, and  aggregate.  For  TOE  units  the  structure  strength 
is  always  at  Level  1.  For  MTOE  and  TDA  units,  the  structure 
strength  is  individually  determined  to  support  the  unit's 
requirements . 

Transaction  Date,  designates  the  last  Julian  date  on  which  a 
record  was  updated. 

Type  MTOE,  identifies  the  TOE  series  of  the  unit  as  defined  in 
the  TAADS,  VTAADS,  and  the  SRCTO. 

Troop  Program  Sequence  Number,  a code  which  groups  units  accord- 
ing to  their  mission  and  si2e. 

Training  Readiness  Condition  Code,  current  overall  readiness 
condition  of  the  unit.  Incorporates  personnel  and  equipment 
readiness  conditions. 

Programed  Transaction  Julian  Date,  designates  the  last  Julian 
date  on  which  a unit  record  is  updated. 

Type  of  Unit  Code,  designates  the  basic  organization  of  unit, 
i.e.,  TOE,  augmentation  to  a TOE,  or  TDA. 

Unit  Identification  Code,  the  alphanumerical  designation  which 
uniquely  identifies  a unit. 

Unit  Capability,  unit  readiness  capability  assigned  by  HQDA 
and  reflected  in  the  TAADS  document. 

Unit  Classlf ication  Code,  aggregate  units  according  to  the 
exact  functions  performed,  i.e.,  air  cavalry,  infantry,  neuro- 
surgical, etc. 

Unit  Readiness  Condition,  current  overall  readiness  condition 
of  the  unit.  Incorporates  personnel  and  equipment  readiness 
condition. 


r-> 


UNMBR 


•*  • 


l. 


UNPID 


UNTDS 


VCHNR 


Unit  Number,  a part  of  the  unit's  description.  For  TOE  units, 
the  UNMBR  is  the  numerical  portion  of  the  unit's  designation. 
TOE  augmentations  carry  the  number  of  the  unit  augmented. 

TDA  units  list  the  first  four  characters  of  the  UICCC  in  this 
field. 

Unit  Package  Identification  Designator,  identification  of  units 
as  a part  of  a specific  force  grouping. 

Unit  Description,  the  unit  title  which  explains  its  functional 
mission.  UNTDS  is  related  to  a unit's  TDSNA,  ELSEQ,  and  SRCTO. 
Voucher  Number,  identifies  the  analyst  who  prepared  the  data 
input . 


8.  INTERFACE  WITH  OTHER  SYSTEMS 


SIGMA  directly  interfaces  the  data  of  three  primary  systems: 

• FAS 

• TAADS 

• TOE 

SIGMA  is,  effectively,  an  interface  evaluation  and  improvement  system. 
Its  task,  as  elaborated  in  preceding  paragraphs,  is  to  assess  the  effec- 
tiveness of  interface  between  the  specified  systems,  where  the  success  of 
interface  is  predicated  upon  inter-file  data  element  value  matches.  Where 
data  element  matches  do  not  obtain  between  files,  error  listings  are 
generated  via  the  SIGMA  edit  option  to  report  mismatch  conditions  to  the 
SIGMA  user.  The  SIGMA  user  then  proceeds  to  use  resources  identified  in 
preceding  paragraphs  to  remedy  the  nonmatching  condition,  thereby  imple- 
menting the  interface  improvement  objective  of  SIGMA. 


1-27 


a 


J 

i 


,3 


3 


3 


APPENDIX  J 


THE  ARMY  AUTHORIZATION  DOCUMENTS  SYSTEM  (TAADS) 


1 . S U B S Y S T EM/  MO  D El.  / DATA  BASF. 

lV 

.1.  Title:  The  Army  Authorization  Documents  System  (TAADS) 

b.  Status:  Operational 

2 . REFERENCES 

a.  Armv  Rop.ul  at  ion  310-49,  Tin*  Army  Author  [ /at  ion  Documents  System 
(TAADS) . 10  June  1975. 

b.  Army  Regulation  310-49-2,  The  Army  Authorization  Documents  System 
(TAADS)  Data  Coding  Procedures,  9 January  1976. 

c.  Army  Regulation  310-49-3,  TAADS  Automated  Support  to  Satellited 
Activities  (TASS A) , 9 January  1976. 

d.  CSR  18-11,  Force  Development  Management  Information  System,  18 
February  1976. 

e.  FORD  IMS  User  Vs  Guide,  Volume  III,  Authorizations  Subsystem,  Unit 
Authorizations  Division,  Office,  Deputy  Chief  of  Staff  for  Operations  and 
Plans,  HQ  DA,  September  1977. 

f.  Interviews: 

Mr.  R.  Adams,  USAMSSA  (AGAM-SDD-A) 

Mr.  A.  Hibbert,  0DSC0PS  (DAMO-FDU) 

Mr.  S.  Haupt,  USAMSSA  (ACAM-SDD-B) 

Ms.  V.  Hughes,  USAMSSA  (ACAM-SDD-C) 

Mr.  C.  Joyce,  USAMSSA  (ACAM-SDD-B) 

Mr.  R.  Walden,  USAMSSA  - FORD  IMS  Development  Team  (ACAM-SDD) 


).  STAFF  PROPONENT 
0DCS0PS  (DAMO-FDU) 


Sources  of  unit  resource  detail  are  an  essential  part  of  SACS  processing. 
Manpower  data  are  required  by  grade,  military  occupational  specialty 
(MOS)  and  branch.  Equipment  data  are  required  by  line  item  number  (LIN). 
A principal  source  since  SACS  inception  lias  been  TAADS.  The  detail 
files  formerly  maintained  at  HQ  DA  by  TAADS  have  now  been  reconstituted 
as  the  Authorizations  Subsystem  (AS)  of  the  Force  Development  Integrated 
Management  Svstem  (FORDIMS).  SACS  systems,  subsystems  and  processes 
have  not  been  modified  to  interface  with  AS.  To  accommodate  that 
situation,  AS  data  are  converted  to  TAADS  format  for  SACS  processing. 
Accordingly,  In  the  basic  report  and  these  appendixes,  reference  is 
made  to  TA\DS  rather  than  AS. 
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a.  Agency:  USAMSSA  (ACAM-SPD-A) 
h.  Equipment : IBM  '370/lb5  or  30  33 


5.  PURPOSE 

a.  Genera  1 

The  purposes  and  objectives  ol  TAADS  are  succinctly  stated  in 
AR  310-49  (AS  objectives  are  essentially  identical)  and  are  excerpted 
be  low : 

• Provide  each  Army  unit  with  a basic  author i ration  document 
which  shows  its  personnel  and  equipment  requirements  and  authorizations. 

• Maintain  overall  HQDA  control  (except  as  specif  leal lv  delegated) 
ot  organizational  structures,  and  requirements  and  author i rat  ions  for 
personnel  and  equipment  in  all  Army  units. 

• Maintain  quantitative  and  qualitative  data  on  personnel  and 
equipment  requirements  and  author i rat  Ions  for  both  individual  Army  units 
and  the  entire  Army  Force  Structure. 

• Establish  current  and  complete  personnel  and  equipment  data 
files  for  use  by  planners,  programmers,  and  resource  managers  at  HQDA, 
at  each  major  Army  command  headquarters,  and  at  selected  Army  installa- 
t ions . 

FORD  IMS  AS,  the  source  of  the  TAADS  data  arravs  used  in  SAGS  pro- 
cessing, maintains  the  detail  files  at  HQDA  of  "documented"  personnel  and 
equipment  requirements  and  authorizations  for  all  Active  Army  and  Reserve 
Component  Modified  Table  ot  Organization  and  Equipment  (MTOE)  and  Table 
of  Distribution  and  Allowances  (TDA)  units.  Manpower  data  are  maintained 
by  Unit  Identity  Code  (UtC),  MOS,  grade  and  branch  while  equipment  is 
Identified  by  UTC,  nomenclature  and  LIN.  For  each  DIG,  the  AS  stores 
the  current  document,  the  programed  document,  and  the  planned  document 
(if  anvl . Thus,  the  svstom  maintains  not  only  current  required  and 
authorized  information  but,  since  a great  portion  of  the  units  have 
projected  requirements  and  author i zat  ions  that  do  not  become  effective 
until  some  later  date,  it  also  contains  these  future  requirements  and 
author  1 z.tt  ions . The  inclusion  ot  future  data  is  made  possible  through 
t he  use  of  effective  dates  (EDA IT) . 


.1-3 


:■ 

It 

I 

II 
I 


L 


i 


I 

4- 

l 

l 


l 


[ 

l 

!. 


I 


I 

1 


r 

1 • 


i 

I . 

I 


f 


b.  Specific 

The  footnote  on  page  .1-2  was  Inserted  to  help  clarify  the  current 
status  of  l'AADS  and  related  systems  and  terminology.  Substantive  changes 
have  taken  place  during  the  past  several  years.  TAADS  was  designed  as 
an  automated  system  used  In  developing  and  documenting  requirements  and 
authorizations  for  personnel  and  equipment  necessary  to  support  the 
assigned  missions  of  Army  units.  The  TAADS  master  file  was  composed  of 
the  current  and  the  history  files,  both  were  subdivided  Into  header  and 
detail  flies,  the  former  known  as  the  TAADS  Summary  Kile,  the  latter  as 
the  TAADS  Detail  File.  USAMSSA  used  to  maintain  these  two  flies  which 
together  constituted  the  TAADS  data  base. 

• TAADS  Summary  files  contained  two  varieties  of  header  records, 
one  applicable  to  MTOEs  and  one  to  TDAs.  Each  header  record  was  designed 
to  accommodate  data  applicable  to  eight  different  authorization  versions 
(time  period  defined  by  successive  EDATEs)  which  could  be  approved  or  in 
the  process  of  being  developed  or  changed.  In  addition  to  authorization 
version  data,  unit  headers  contained  D1C  and  Security  Class  (CLASS). 

Each  of  the  eight  authorization  version  data  blocks  contained  data  essen- 
tial to  its  identification  and  use  in  TAADS. 

- TDA  headers  contained  the  following  information  in  each 
authorization  version  data  block: 

Command  and  Control  Number  (CCNUM) 

EDATE 

Command  of  Assignment  Code  (CMD) 

Phase  Code  (PHASE) 

- MTOE  headers  contained  the  following  information  In  each 
authorization  version  data  block: 

CCNUM 

EDATE 

Master  Standard  Requirements  Code  (SKCMS) 

1 .eve  1 - Eq u Ipmen t ( EQULC ) 

Love l -Per sonne 1 (PERLEV) 

Base  Authorization  (BAUTH) 

MTOE  Modification  Number  (MCNVM) 
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• TAADS  Detail  files  included  two  varieties  of  detail  records. 
One  applied  to  personnel,  the  other  to  equipment.  Personnel  detail 
records  were  distinguished  from  equipment  detail  records  by  Record 
Control  Number  (RCNUM) . Each  personnel  and  equipment  detail  record  was 
designed  to  accommodate  required  and  authorized  quantitites  for  eight 
authorization  versions  corresponding  to  those  in  the  header  records 
described  above. 

- Personnel  detail  records  were  identified  by  RCNUM  "A"  and 
contained  the  following  data  elements: 

UIC 

Grade  (GRADE) 

Military  Occupational  Specialty  (MOSCO) 

Miltiary  Branch  (BRCHP)  - Civilian  Category  (CIVCAT) 

Army  Management  Structure  Code  (AMSCO)  - TDA  only 
Identity  (IDENT)  - TDA  only 
Remark-Personnel  (PERMK) 

- Equipment  detail  records  were  identified  by  RCNUM  "B"  and 
contained  the  following  data  elements: 

UIC 

LIN 

Remark-Equipment  (RMKEQP) 

At  about  the  end  of  December  1977,  the  TAADS  Detail  File  was 
incorporated  into  FORDIMS  as  AS . The  TAADS  Summary  File  is  to  be 
incorporated  into  FORDIMS  at  a later  date. 

AS  is  currently  operational.  It  accepts  data  from  the  field 
through  the  extension  of  TAADS  to  the  major  commands  (MACOMs) . That 
extension  is  known  as  Vertical  TAADS  (VTAADS) . A further  extension 
links  the  system  to  installation  level  and  is  known  as  Installation 
TAADS  (ITAADS).  The  flow  of  information  through  ITAADS  and  VTAADS  keeps 
the  system  up  to  date.  These  data  are  then  used  to  produce  the  various 
detail  reports  identified  in  Reference  2e,  above  (includes  Personnel 
Detail  Reports,  Equipment  Detail  Report,  Header  Lists,  Audit  Reports, 
and  Document  Level  Reports).  However,  AS  detail  data  are  not  acceptable 
for  use  in  the  Automated  Update  Transaction  System  (AUTS) , the  process 
used  to  update  the  Force  Accounting  System  (FAS).  Further,  AS  detail 
data  are  not  acceptable  for  use  in  SACS. 
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Therefore,  it  is  necessary  for  USAMSSA  to  summarize  the  detail 
data  in  AS  using  the  pre-existing  Detail  TAADS  and  Summary  TAADS  formats. 
Once  FORDIMS  has  been  completely  implemented  (about  March  1980),  FAS 
will  be  incorporated  into  FORDIMS  as  the  Force  Structure  Subsystem  (FSS) 
and  the  AUTS  process  will  no  longer  be  required.  However,  SACS  and 
SACS-related  software  will  probably  require  modification  to  accept  some 
revised  data  formats. 

We  have  described  above  the  flow  of  TAADS  data  and  have  noted 
that  (through  AS)  the  Detail  TAADS  and  Summary  TAADS  files  can  be  up- 
dated whenever  required.  However,  as  a result  of  the  Management  of 
Change  (MOC)  study,  HQDA  established  two  90-dav  windows  each  year  for 
the  submission  of  documents  by  the  field  to  update  the  files.  These 
two  periods  end  on  31  March  and  30  September.  Each  V'TAADS  update  sub- 
mission is  accompanied  by  a letter  of  transmittal  which  provides  an 
indication  of  the  data  (by  unit)  that  have  been  included  in  that  VTAADS 
submission  by  the  applicable  field  activity.  This  letter  is  received 
in  triplicate  and  is  distributed  to: 

• ODCSOPS  (DAMO-FDU) 

• ODCSPER  (DAPE-MBA) 

• 0DCSI0G  (DALO-PLF  for  the  Equipment  Authorization  Review 
Activity  of  DARCOM) 

These  VTAADS  document  submissions  are  reviewed  and  any  problems 
that  may  surface  are  resolved  with  the  field  activity  concerned. 

6.  CONTRIBUTION  TO  SACS 

TAADS  data  are  an  essential  element  of  the  SACS  process  through 
which  unit  resource  documentation  is  "matched"  to  the  Army  Force  Program. 
In  a SACS  study,  the  units  which  compose  the  force  to  be  studied  are 
first  extracted  from  FAS.  This  selected  file  of  units  is  then  matched 
against  TAADS  resource  documentation  in  a first  order  effort  to  match 
each  selected  unit  with  its  MTOE  or  TDA  personnel  and  equipment  detailed 
"authorizations."  While  there  are  additional  and  alternative  organiza- 
tional structure  match  and  resource  detail  processes  which  are  subse- 
quently applied,  TAADS  provides  the  critical,  detailed,  first  order  unit 
and  resource  documentation  data  base. 
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7 • MAJOR  DATA  ELEMENTS 

Appendix  D of  Reference  2e,  above,  contains  a complete  listing  of  data 
elements  applicable  to  FORDIMS  AS.  As  outlined  at  several  points  herein- 
above, AS  data  output  are  not  acceptable  for  use  in  SACS.  Accordingly,  in 
the  interest  of  compatibility  and  completeness  there  are  listed  below  major 
data  elements  of  the  pre-existing  TAADS  data  base. 

AMSCO  Army  Management  Structure  Code,  classification  of  Army  activities 
and  functions. 

ASICO  Additional  Skill  Identifier  Code,  identifies  additional  special 
skills  required. 

ATCOD  Action  Code,  identifies  the  type  of  action  (add,  change,  or 
delete) . 


AUAGR 

Authorized 

Military  Aggregate. 

AUCIV 

Authorized 

Civilian  Aggregate. 

AUENL 

Authorized 

Enlisted . 

AUFND 

Authorized 

Foreign  National  Direct  Hire. 

AUIDH 

Authorized 

Indirect  Hire. 

Al’OFF 

Authorized 

Officers. 

AUSTR 

Authorized 

Strength,  Indicates  strength  for  specific  types  of 

personnel  by  grade,  identity,  or  branch  (Includes  civilians). 


Al’TEQ  Authorized  quipment  Quantity. 

AUUSD  Authorized  US  Direct  Hire,  total  authorized  US  direct  hire 
(USDH)  spaces. 

AUWOF  Authorized  Warrant  Officer,  total  authorized  warrant  officer 
spaces . 

BCCNO  Base  Command  Control  Number,  CCNUM  of  the  document  used  for 
modification. 

BDOCN  Base  Document  Number,  for  MTOE  identifies  the  base  TOE  number 
plus  command  code,  plus  modification  number.  For  TDA  identi- 
fies the  UIC,  parent  unit,  command  and  MO  for  MOBTDA. 

BRNCH  Branch  or  Civilian  Category  Code,  identifies  the  military 
branch  or  duty  detail  for  officers,  and  warrant  officers 
(optional  for  commissioned  officers).  Also,  for  TDA,  iden- 
tifies civilian  categories. 
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CATCO  Unit  Category  Code,  identifies  TOE/MTOE  units  as  belonging  in 
one  of  three  categories  according  to  their  mission  and  normal 
locations . 

CCNUM  Command  and  Control  Number,  identifies  the  number  of  changes 
applied  to  a MTOE  or  TDA  document  during  a fiscal  year. 

CICCO  Controlled  Item  Code,  indicates  equipment  item  as  DA  authorized 
and  designated  for  centralized  management. 

CLASS  Security  Classification,  identifies  the  classification  of  MTOE 
or  TDA  document. 

DDMBL  Date  DMB  Received-LOG,  identifies  date  IAR  is  provided  to 
USAMSSA  Data  Management  Branch  Logistics  Section. 

DDMBP  Date  DMB  Received-PER,  identifies  date  IAR  is  provided  to 
USAMSSA  Data  Management  Branch  Personnel  Section 

DEDTE  Document  EDATE,  identifies  earliest  effective  date  for  any 
unit  included  in  an  MTOE  document.  The  effective  date  of  a 
TDA  document. 

DOCNO  Document  Number,  identifies  the  MTOE  or  TDA  number. 

(MTOEC) 

EDATE  Effective  Date,  identifies  the  date  that  a MTOE  or  TDA  docu- 
ment applies  to  a specific  unit  (organization,  activation, 
reorganization,  discontinuance,  or  inactivation  date). 

EQRMK  Equipment  Remark,  identifies  a remark  in  a MTOE  or  TDA  docu- 
ment that  provides  guidance  for  distribution  or  restricted 

issue  and  usage  of  certain  equipment. 

FRCMD  Command  from  Which  Document  Came,  identifies  the  command 
designated  by  HQDA  that  will  receive  an  approved  MTQE/TDA 
document. 

GRADE  Grade  Code. 

IDENT  Identity  Code,  identifies  the  type  of  personnel  (military  or 

civilian) . 

INCDE  Installation  Code,  identifies  installations  having  an  ITAADS 

capability. 

LEVEL  Authorized  Level  of  Organization  Code,  identifies  the  level 
of  MTOE  authorized  organization. 
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LICCO 


LINUM 

MACOM 

MOSCO 

NOMEN 

NSRMK 

PHASE 

POSIT 

PRMK  16.2 

PUAST 

PURST 

REQEQ 

RQAGR 

RQCIV 

RQENL 

RQFND 

RQIDH 

RQOFF 

RQSTR 

RQUSD 


Language  Identification  Code,  Identifies  special  language 
capability. 

Line  Item  Number,  identifies  the  generic  nomenclature  of 
authorized  equipment  items. 

Command  Code,  identifies  the  proponent  command  or  subcommand. 
Military  Occupational  Specialty  Code. 

Equipment  Nomenclature. 

Non-Standard  Remark  Code,  identifies  a three-position  numeric 
code  (200-999)  that  applies  to  non-standard  remarks. 

Phase  Code,  identifies  the  status  of  a document. 

Duty  Position  Title,  the  title  of  a position  or  job  in  a MTOE 
or  TDA  document. 

Personnel  Remarks  One  and  Two,  identifies  the  additional  duty 
requirements  of  personnel  authorization  in  a unit. 

Parent  Unit  Authorized  Strength,  identifies  the  total  authorized 
strength  of  a unit  including  its  subelements. 

Parent  Unit  Required  Strength,  identifies  the  total  required 
strength  of  a unit  including  its  subelement. 

Required  Equipment  Quality,  identifies  the  quantity  of  equip- 
ment required. 

Required  Military  Aggregate,  identifies  the  total  of  all  of 
the  required  spaces  in  a MTOE  or  TDA  document. 

Required  Civilian  Aggregate,  identifies  the  total  of  all  of 
the  required  civilian  spaces. 

Required  Enlisted,  identifies  the  total  of  all  required  enlisted 
spaces. 

Required  Foreign  National  Direct  Hire,  identifies  the  total  of 
all  required  direct  hire  foreign  national  (DHFN)  spaces. 

Required  Indirect  Hire,  identifies  the  total  of  all  required 
indirect  hire  (IDH)  spaces. 

Required  Officers. 

Required  Strength,  identifies  the  grand  total  of  all  required 
military  and  civilian  spaces. 

Required  US  Direct  Hire,  identifies  the  total  of  all  required 


total  direct  hire  US  (DHUS)  spaces. 
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RQWOF  Required  Warrant  Officers. 

RTEXT  Remark  Text,  provides  a narrative  description  of  a remark 

code  (either  personnel  or  equipment;  standard  or  non-standard). 
SCCNO  Superceded  CCNUM,  identifies  the  CCNUM  but  has  been  replaced 
by  the  new  CCNUM. 

SDOCN  Superceded  DOCNO,  identifies  the  CODNO  but  has  been  replaced 
by  the  new  DOCNO. 

SEQNO  Sequence  Number,  controls  line  sequence  in  non-standard  re- 
marks. 

SPARA  SRCOD  Paragraph,  identifies  a paragraph  number  in  the  TOE 
document  used  for  modeling  a MTOE. 

SQICO  Special  Qualifications  Identifier,  identifies  special  qualifica- 
tions personnel  requirements. 

SRCOD  Standard  Requirements  Code,  identifies  a basic  TOE  or  elements 
and  variations  thereof  (MTOE) . 

STEXT  Section  I Text,  identifies  a line  of  text  in  Section  I of  a 
MTOE  or  TDA  document. 

SUBCO  MTOE  Sub-Unit  Code,  defines  the  sub-unit  of  a parent  battalion 
or  squadron.  Also  called  the  UIC  descriptive  designator. 

TOETL  TOE  Title,  identifies  the  complete  title  of  a TOE  document. 

UICOD  Unit  Identification  Code,  identifies  a code  that  uniquely 

identifies  an  organization. 

UNTDS  Abbreviated  Unit  Description,  identifies  the  shortened  title 
of  a unit. 

8.  INTERFACE  WITH  OTHER  SYSTEMS 

a.  Automated  Update  Transaction  System  (AUTS) 

In  this  system  TAADS  is  matched  against  the  FAS  on  a monthly 
(or  as  required)  basis  for  the  purpose  of  determining  if  the  latest 
documented  unit  data  recorded  in  TAADS  has  been  or  should  be  entered 
into  FAS. 

b . Force  Accounting  System  (FAS) 

This  is  the  major  system  with  which  TAADS  interfaces.  As  noted 
in  the  preceding  subparagraph,  TAADS  is  used  as  the  basis  of  documented 
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unit  data  in  FAS.  TAADS  interfaces  with  FAS  during  SACS  processing.  In 
a SACS  study,  units  which  are  relevant  are  extracted  from  FAS.  TAADS  is 
then  searched  to  determine  if  the  units  are  contained  in  the  TAADS  file. 
If  the  unit  is  found  in  the  TAADS  file,  detailed  personnel  and  equipment 
authorizations  extracted  from  these  records  are  used  in  calculating  force 
requirements  and  authorizations. 

While  FAS  contains  no  equipment  authorizations,  it  does  contain 
manpower  authorizations  aggregated  by  personnel  identity.  The  major 
linking  data  elements  common  to  TAADS  and  FAS  are: 

• Unit  Identification  Code 

• Effective  Date 

• Command  Control  Number 

• MTOE  Number 

• Standard  Requirements  Code 

• Army  Management  Structure  Code 

• Structured/Required  Strength 

- Officer 

- Warrant  Officer 

- Enlisted 

- Military  Aggregate 

- Civilian  Aggregate 

• Authorized  Strength 

- Officer 

- Warrant  Officer 

- Enlisted 

- Miltiary  Aggregate 

- US  Direct  Hire 

- Foreign  National  Direct  Hire 

- Indirect  Hire 

- Civilian  Aggregate 

c . Army  Force  Program  (AFP) 

The  AFP  is  an  automated  management  information  system  (MIS)  used 
within  HQDA  to  produce  guidance  and  audit  trails  for  Program  Budget 
Guidance  (PBG)  documents.  Through  this  process  major  commands  are 
informed  of  the  changes  in  manpower  allocation  (i.e.,  changes  in 
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manpower  allocations  for  the  current,  and  budget,  and  program  years. 
TAADS  and  AFP  can  be  linked  by  major  command  and,  theoretically,  HQDA 
guidance  provided  in  the  PBC  should  be  reflected  eventually  in  the  TAADS 
file.  There  is  no  current  procedure  for  linking  the  PBG  guidance  to 
the  field  implementation  in  MTOE/TDA  documents.  However,  DCSOPS  is 
currently  preparing  to  implement  a guidance  tracking  process  which  will 
ensure  that  authorization  documents  are  either  in  balance  with  guidance 
or  that  any  imbalances  are  auditable.  TAADS  has  the  following  major 
data  elements  in  common  with  AFP: 

• Army  Management  Structure  Code 

• Major  Command 

• Structure/Required  Strength 

- Officer 

- Warrant  Officer 

- Enlisted 

- Military  Aggregate 

- Civilian  Aggregate 

• Authorized  Strength 

- Officer 

- Warrant  Officer 

- Enlisted 

- US  Direct  Hire 

- Foreign  National  Direct  Hire 

- Indirect  Hire 

- Civilian  Aggregate 

d.  Civilian  Budget  System  (CBS') 

The  CBS  is  designed  to  provide  automated  support  to  the  civilian 
manpower  programing  and  budgeting  process  and  to  establish  a civilian 
manpower  and  cost  structure  which  can  be  used  to  analyze  the  impact  of 
program  and  budget  decisions  on  given  force  structure.  Authorized 
civilian  end  strengths  shown  in  CBS  for  a command  should  ultimately  be 
reflected  in  TDA  authorization  documents  in  TAADS.  There  is  no  current 
procedure  to  track  guidance  from  CBS  to  ensure  proper  implementation  in 
TAADS  TDA.  The  guidance  tracking  process  when  implemented  will  provide 
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this  link.  TAADS  TDA  files  have  the  following  data  elements  in  common 
with  CBS: 

• Command  Assignment 

• Army  Management  Structure  Code 

• Authorized  Civilians 

- US  Direct  Hire 

- Foreign  National  Direct  Hire 

- Indirect  Hire 

- Civilian  Aggregate 

e . The  SACS  Information  Gathering  and  Management  System  (SIGMA) 

SIGMA  is  a computer  terminal  system  which  provides  a capability 

of  replicating  the  initial  phases  of  a SACS  computation  in  a more  rapid 
fashion  than  in  SACS.  Its  objective  is  to  assure  an  error-free  inter- 
face between  the  FAS,  TAADS,  and  TOE  systems  when  united  in  a SACS 
environment.  SIGMA  requires  an  input  of  the  Forces  File  from  FAS  which 
is  to  be  used  in  the  SACS  computation,  a Notes  File  from  FAS  compatible 
with  the  force  selected,  a TAADS  header  file  with  type  personnel  strengths 
as  used  by  the  FAS/TAADS  overlay,  and  a TOE  computational  file  with  type 
personnel  summary  strengths. 

Through  SIGMA  the  analyst  knows  which  of  the  units  selected  for 
the  SACS  computation  do  not  have  authorization  documents  and  how  closely 
units  with  authorization  documents  in  TAADS  and  TOE  match  current  strength 
data  in  FAS. 

f . Basis  of  Issue  Plan  (BOIP)  System 

BOIP  provides  current  information  regarding  changes  in  personnel 
and  equipment  requirements  due  to  the  initial  issuance  of  new  or  improved 
items  of  equipment.  Changes  in  requirements  are  detailed  for  each  type 
of  Army  unit  affected  for  a specified  time  frame.  The  Standard  Require- 
ments Code  (SRC)  identifies  each  of  these  types  of  units. 

BOIP  and  TAADS  interface  principally  in  LOGSACS  computations 
where  TAADS  equipment  line  item  requirements  are  altered  by  BOIP  to 
reflect  planned  changes.  BOIP  is  not  used  in  a PERSACS  computation. 

The  major  common  data  elements  in  TAADS  and  BOIP  are: 

• Standard  Requirements  Code 

• Additional  Skill  Indicator 
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• Line  Item  Number 

• Branch 

• Grade 

• Military  Occupational  Specialty 

• Quantity 

g.  Rapid  Authorization  Data  Retrieval  (RADAR) 

The  RADAR  system  provides  the  functional  analyst  with  quick, 
responsive  strength  reports  for  all  major  data  elements  in  the  TAADS 
data  base  as  well  as  MTOE  and  TDA  documents  for  any  given  unit  (per- 
sonnel/equipment only  or  both)  via  CRT  (with  optional  hard  copy).  RADAR 
has  two  da(a  retrieval  option  lists.  The  first  contains  options  for  the 
entire  TAADS  file;  the  second  permits  the  user  to  create  a force  of  units 
using  up  to  six  different  parameters  (STACO,  TPSN,  SRC,  MTOE,  Batch  of 
UICs , and  LOCCO  from  the  TAADS  file). 
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APPENDIX  K 

THE  TABLES  OF  ORGANIZATION  AND  EQUIPMENT  (TOE)  SYSTEM 
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1.  SUBSYSTEM/MODEL/DATA 


a.  Title:  The  Tables  of  Organization  and  Equipment  (TOE)  System 

b.  Status:  Operational 


2 .  REFERENCES 


Army  Regulation  310-31,  Management  System  for  Tables  of  Oreaniza- 


tion  and  Equipment  (The  TOE  System),  2 September  1974. 

b.  CSR  18-11,  Force  Development  Management  Information  System, 
18  September  1976. 


Interviews : 


Mr.  W.  C.  Braswell,  0DCS0PS  (DAMO-RQR) 
Mr.  R.  Adams,  USAMSSA 


3.  STAFF  PROPONENT 


0DCS0PS  (DAMO-RQR):  While  this  Office  exercises  Army  General  Staff 
responsibility,  US  Army  Training  and  Doctrine  Command  (TRADOC)  has  been 
charged  with  TOE  development  and  systems  maintenance. 


4 .  COMPUTER  SUPPORT 


a.  Agency:  USAMSSA-MSB 

b.  Equipment:  IBM  370/165  or  3033 


5.  PURPOSE/ROLE 


a.  The  TOE  System  provides  the  method  by  which  the  personnel  and 
equipment  requirements  for  combat,  combat  support,  and  combat  service 
support  units  are  structured  and  documented. 


b.  TOE  maintains  data  listing  personnel  (at  various  authorized  levels 
of  organization  (ALO))  and  equipment  (at  various  ALO)  for  "Standard" 
unit  types.  These  lists  are  used  as  a basis  on  which  to  build  actual 
authorization  and  requirement  lists  for  individual  units  as  represented 
in  The  Army  Authorization  Documents  System  (TAADS)  as  modified  TOE  (MTOE) . 


MTOF.  units  contain  no  civilian  strengths. 


Each  TOE  is  identified  by  a Standard  Requirements  Code  (SRC) 


and  is  used  as  the  authorizations  source  when  MTOE  units  have  no 


authorization  documents  in  TAADS. 
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6 . CONTRIBUTION  TO  SACS 

a.  TOE  Is  used  in  the  SACS  matching  process.  The  resulting  file, 
when  used  in  combination  with  similar  files,  provides  audit  trail  Infor- 
mation in  the  SACS. 

b.  The  matching  process  evolves  from  the  procedures  used  during 
SACS  in  which  each  unit  record  selected  from  the  Force  Accounting  System 
(FAS)  is  matched  against  the  TAADS  Summary  and  Detail  Files.  During 
the  course  of  the  match  certain  FAS  records  will  not  match  a TAADS  docu- 
ment. There  are  several  reasons  for  this  occurring,  e.g., 

• No  authorization  document  for  the  unit  in  TAADS. 

• Incorrect  MTOE  or  TOE  identified  in  FAS. 

• Unit  deliberately  forced  to  mismatch  TAADS. 

Using  the  SRC  Codes,  which  the  TOE  system  contains,  SACS  matches  the 
unmatched  units  to  the  TOE  data  base,  and  thus  develops  the  lists  of 
personnel  and/or  equipment  for  these  units.  An  impact  file  is  also 
created  which  shows  the  results  of  the  TOE  match. 

7.  MAJOR  DATA  ELEMENTS 

AS ICO  Additional  Skill  Indicated  Code. 

BRNCH  Branch.  Identifies  the  branch  of  service  under  which  a TOE 
unit  is  organized. 

GRADE  Grade.  Identifies  the  grade  of  the  authorized  position. 

LINUM  Line  Item  Number.  Identifies  the  Alpha-numeric  line  number 
assigned  to  an  item  of  equipment. 

MOSCO  Military  Occupational  Specialty  Code. 

RMKS1  Remarks . Identifies  further  discriminators  of  MOS  and  position 

requirements. 

RMSK2  Remarks.  Identifies  further  discriminators  of  MOS  and  position 
requirements. 

SRCTO  Standard  Requirements  Code.  Identifies  the  basic  authorization 
of  both  personnel  and  equipment  for  a TOE  unit. 

RQTOE  Required  TOE  Strength.  This  is  the  Strength  Level  of  the  TOE 

unit  and  is  always  at  ALO  1.  Included  is  the  required  strength 
for  Officers,  Warrant  Officers,  and  Enlisted. 
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8.  INTERFACE  WITH  OTHER  SYSTEMS 


a.  TOE  provides  standard  organizational,  personnel  and  equipment 
data  to  TAADS  for  use  in  building  MTOEs , if  and  when  required. 

b.  AUTS  uses  the  TOE  file  when  a mismatch  occurs  between  the  FAS 
and  TAADS . An  attempt  is  made  to  obtain  a FAS  vs.  TOE  match. 

c.  TOE  provides  requirements  data  to  the  SRC  assembly  process  when 
more  than  one  SRC  is  involved  with  a unit. 

d.  TOE  is  a data  source  for  SIGMA  when  FAS  units  are  mismatched  to 
TAADS.  TOE  becomes  the  alternate  data  source  to  match  to  FAS. 
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